Looking for papers about 'Dealing with workflows in Smalltalk'

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

Ok, it's 5 minutes on your side and 3 months on mine... At the end, we
can produce a very interesting browser for all of you.

Are you sure you don't have any links or ideas ?

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:

Simon Kirk a écrit :
> Hi Damien.

Hi Simon,

> 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 :)


Experienced Smalltalkers have full of ideas and I'm glad to hear your
opinion. Thank you for answering.

> 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.


Exactly


> 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

This discussion is very interesting ("Squeak, source control,
subversion, versioning, monticello, all that good stuff")

> 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 :)


This is an interesting idea we could work on.


> [...]
> 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.


We would like to work on this too.


> 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.


I didn't know Scrum, thank you for this.



It is, thank you

Hi damien

here is a list:

- we need smart categories (where we can drop what we want, even to  
do items)
        cf starbrowser

- if would be good to have path in the browsed classes (like in the  
forest):
the last time you came in the class you look at these methods

- multiple panes for simultaneous method browsing
        cf whisher

- support for refactoring and consistent key binding everywhere (in  
VW this is broken)
you cannot extract a method from the debugger and some key binding do  
not work in different tools.

- Sometimes I would like to browse a class and all its collaborators  
(using dirrect reference to classes or typer result)
and I do not want to see all the other classes in the same packages.

- We should always be able to see the superclass chain in any  
browser. In squeak this is really missing.
Opening yet another browser is a bad idea.

Thank you for this ideas. They are helpful and we might base our work on
such kind of ideas.

Thanks

Le Wednesday 28 June 2006 10:36, stéphane ducasse a écrit :
> Hi damien
>
> here is a list:
Hi Stephane

some of functionalities you are looking for are implemented in tamaris.
>
> - we need smart categories (where we can drop what we want, even to
> do items)
> cf starbrowser
cf tamaris
>
> - if would be good to have path in the browsed classes (like in the
> forest):
> the last time you came in the class you look at these methods
cf tamaris ?
>
> - multiple panes for simultaneous method browsing
> cf whisher
cf tamaris
>
> - support for refactoring and consistent key binding everywhere (in
> VW this is broken)
> you cannot extract a method from the debugger and some key binding do
> not work in different tools.
>
> - Sometimes I would like to browse a class and all its collaborators
> (using dirrect reference to classes or typer result)
> and I do not want to see all the other classes in the same packages.
cf tamaris ?
>
> - We should always be able to see the superclass chain in any
> browser. In squeak this is really missing.
cf tamaris
> Opening yet another browser is a bad idea.

alain