Build Relationships

I guess it is Extreme Programming Day here at Making It Stick.

Kent Beck writes about planning...

We deliver functionality but we build relationships. Planning is more about building relationships than it is about delivering functionality.

I teach a "whole team" Agile/XP course a half dozen times a year. I emphasize values a much as practices. Communication is the value at the top of the list. We also spend a significant bit of time discussing how to adopt XP. My first (and often repeated) message is, if you can only take one thing out of this course then take the benefits of "clear communication with your whole team" into whatever practices you do choose.

Not only is communication the most important value it is also the easiest thing to adopt as an individual under any circumstances. Build relationships.

Slowing Down

Ron Jeffries on the pace and stress of software development...

If you're feeling under the gun, it might be time to slow down.

Amazingly counter-intuitive advice is found throughout Extreme Programming practices. I have *never* seen continued pressure and stress succeed in software development. On the other hand more than once I have seen big improvements when teams are able to step back, breath, make a couple of observations, and move forward gradually. Before long the team is working better than ever.

Courage and Trust in Software Development

Bill de hOra writes...

While refactoring is important for codebases that are expected to provide a product dynasty rather than a legacy mess, it's often devalued as mere tinkering by those removed from source code, as it doesn't provide new functionality - it can be very difficult to explain to a non-expert why not adding, or even delaying features now, will help with delivery of features later.

I think there are several ways to approach this devaluation. One is, do things in small pieces whenever possible. A little refactoring following a little vlaue adding is hardly noticeable.

A frequent question I get in the face of this kind of devaluing is, "Should we just do X and not tell them?" My sense is that sometimes may be advantageous when adopting a practice that has been unduly questioned. But my advice is not to make a habit of this. An important goal is to build an effective whole team, and deception in any significant, ongoing, way cannot be effective in the long run.

There is a more positive approach to this kind of behavior. That is to revisit the roles and responsibilities of developers and other stakeholders. In this case, developers have the responsibility to improve the design when they believe they'll get better at adding value in the longer run. Stakeholders having the courage to trust their developers is as important as those developers having the courage to admit they need to go through a significant refactoring for some reason.

Most software development practices over the last several decades have not brought courage and trust into the equation. Making these values part of the discussion is a clear advantage to agile methods and Extreme Programming. Scary, but better to be encouraged to courageously dive into the depths of what will haunt you anyway, even if ignored.

That's It

Bill de hOra...

We can see the market looking at 3 things to provide value in software solutions:

1. Simple protocols and formats
2. Open source infrastructure
3. Agile methodologies

All of these are disruptive.

Skiplists in C# and Smalltalk

This on data structures recently from MSDN...

Skip lists are an ingenious data structure that turns a linked list into a data structure that offers the same running time as the more complex self-balancing tree data structures... In the latter part of the article, we'll be building a skip list class in C#, which can be downloaded.

Cool.

I recently had a use for a skip list in Smalltalk and could not find code I wrote a significant number of years ago. So I got out the trusty skiplist cookbook.

Fortunately I did not get far before discovering that skip lists are available "out of the box" in Squeak.

New Functional Geometry

Bill Clementson references a functional programming book chapter on functional geometry. (Part of a really interesting book from the early 1980's still worth reading.)

As it turns out the functional geometry presentation has been updated.

The Future of SOAP

James Governor writes...

One big question is why haven't IBM and Microsoft responded? The obvious answer is vested interest. When you have "bet the company" on a technology stack its kind of a drag to have to respond to something else. Its interesting that in a week when the bug guys, including Gartner, have trumpeted the arrival of UDDI 3.0, the world is quietly getting on with more interesting projects.

Smalltalk Evolution

The question is raised, how does Smalltalk evolve?

My answer is "very little". Smalltalk is not perfect, but is high up on the list of near-perfect languages. Any radical changes are better off being put into a new language. Otherwise the change can be put into one of the open source Smalltalk implementations and adopted ad hoc. That's your choice and right. If the change succeeds wildly the community will adopt it for you.

Meanwhile there is controversy over the leadership of Squeak. I don't know the whole story here but this is open source. They seem to be mostly supported and they've stepped up to the task, so good on them. It's not like they should be taking the language in radical directions.

Fork the language under a new name for radical changes. Let Smalltalk be Smalltalk at this point. I think the limitations of other languages lead their communities into a mindset of constantly adding features as if it were a Microsoft Office product.

Less is More

Blaine Buxton makes an often discounted observation...

Removing code means you are simplifying the code and the result is a net gain. So, next time, you're refactoring and deleting code. Don't think of it as deleting, but as gaining code via simplicity.

Blaise Pascal is quoted as saying...

I have made this letter longer than usual, because I lack the time to make it short.

Shell Scripting

Danny Ayers is looking for a shell script to keep another process alive. I'm sure I won't do better... I do as little shell scripting as possible. Shell programming never seemed aimed at humans.

Everything I've wanted to do manually in a shell script I have done more easily in Emacs or some other interactive programming environment involving Lisp or Smalltalk. For automated tasks its as easy to schedule a Lisp script as easily as bash. The trick in the past was using a small Lisp like XLisp or one that generates small apps like Gambit Scheme. That's still the trick but there are more choices.

Many Lisp implementations these days understand the #! notation to run as a script. Another option is to use scsh, the Scheme Shell.