Looking for papers about 'Dealing with workflows in Smalltalk'

Simon Kirk simon.kirk at pinesoft.co.uk
Tue Jun 27 11:57:44 UTC 2006


Hi Damien.

I am very interested in this kind of thing, unfortunately my
understanding and/or point of view is fashioned via experience rather
than any particular papers/publications/code, but I'll plough on
regardless :)

Just to be clear on definition, by "workflow" I am thinking in terms of
a developer's day-to-day development work (be that design, coding,
writing of unit tests, whatever) and its integration with both a
work/bug/whatever-tracking system and a source-control system.

A while ago I posted a rather large (and largely uninformed) email to
the list about Monticello trying to get some answers up-front before I
had ever used it in anger, with respect to integrating it into a model
of developer workflow.

Too stop this turning into more of a tome then it already is, here's the
gmane link to the email: http://shrunk.net/472063cf

In reply Avi came up with a suggestion of how to loosely (ie not
restricted programmatically, just conventionally) model this workflow
with Monticello here: http://shrunk.net/47742a1b (there were lots of
other useful replies, sorry I can't quote them all).

These days I know MC much better - so I can understand his suggestion,
and it's good. Of course, in an ideal world, the browser would
provide a framework for the developer to support a workflow like this.
This is where you guys step in :)

As an aside, it has always one of my primary requirements for any such
tools and workflows has always been to absolutely minimise impact on
design and development time.

So that's a coupling of development and source control workflow. But
there are other things to consider that I am very interested in, too.

1. The explicit coupling of tools with the bug tracking system in
smalltalk - this is currently completely unsupported. I have written PHP
tools like this to integrate file-based development with svn and Mantis,
and they work pretty well. I have held off doing tools like this in
Smalltalk yet, though, because I've heard rumour of a very flexible and
powerful bug (and other things) tracking system arriving in Squeak in
the near future.

2. The integration of other steps of workflow - in fact perhaps the
three most important: Design, Unit test development (ie "up-front" TDD
rather than "when there's time" testing), and code review.

This coordinates interestingly with Agile methodoloies. In Scrum there
needs to be a clearly defined value of "Done" for any bit of work, that
ought to mean something like "well designed, cleanly coded, unit tested,
refactored and peer code reviewed". Any tool that attempts to aid
developer workflow would do well to aim to help a developer achieve this
level of "doneness" in a well defined and repeatable manner.

A final note, regarding tools to aid code review: Cenqua are a company
who write a very useful subversion/CVS analysis tool called Fisheye.
They are also now in beta of a tool that integrates Fisheye with a code
review framework called Crucible. It may be worth taking a look at that
as an idea of how to model the code review part of developer workflow,
as Cenqua traditionally (in my experience anyway) create well thought
out and useful tools.

I meant this email as an open discussion of my ideas regarding developer
workflow work, hence the length. I hope it can be of some use!

Cheers,
Simon

Damien Cassou wrote:
> Hi,
> 
> Karsten Kusche and I are working for Georg Heeg eK to improve Smalltalk
> developers workflow while keeping flexibility. Ideas have to be grabbed
> to help average Smalltalk developers to make a good design and follow an
> established workflow.
> 
> We would like to finish our work with a tool that everybody can use for
> development. It should be an extension to the existing browser that
> displays more information.
> 
> Attention is being put in easing unit tests, making the comprehension of
> an existing system simpler, and giving lots of information about
> methods, classes and packages.
> 
> 
> If you have ideas, publications or things that we can test or read, it
> would be interesting to share with us.
> 
> 
> Thank you for your help, we hope we will be able to present something at
> ESUG 2006.
> 
> 
> Bye
> 
> -- 
> Damien Cassou
> 
> 
> 




More information about the Squeak-dev mailing list