Smalltalk-80 had a fantastic work-management facility. I haven't checked lately but I think Squeak and Pharo Smalltalk environments still have it.
On the desktop of Smalltalk Virtual Image you can right-click and say "New Project". This open a new window, which you can resize as you wish. Right-clicking on that allows you to "Enter Project". When you do you see a new desktop into which you can open various tool-windows, browsers, debuggers etc. And you can open nested project-windows inside a project-desktop, as deep as you wish. You can exit a (sub-) project but the (sub-)project still remains in existence, with its window in the parent-project as the handle to it.
As you exit your Smalltalk session you typically choose to "Save Image" which means this tree of projects, each having its own state and set of windows, perhaps a debugger halted on a piece of code, are saved with it. (You will see them the next time you re-open that same saved Smalltalk image).
When you're working on something you often discover that to do this you must first do something else. No problem, open a new "project" window on your current Smalltalk (project-) desktop. Once that sub-task is done you can exit that project and close its window. But you can have multiple (nested) sub-tasks open at the same time.
The name "project" is not the best word for them I think, I think they should be called "tasks". Why does that matter? Because I think it's important to understand that this is not about Project Management. This is Task Management. Something in the spirit of mise-en-place perhaps. You could create a Smalltalk image with tree of "project windows" on it and share it with your co-workers. These sub-projects could describe the subtasks and allow you to record you progress in them, say for cooking a specific type of dinner.
Smalltalk "project-windows" are such a great idea I wonder why something like them does not exist in other environments. No doubt having a "Virtual Machine" whose state is easily saved is a requirement.
It doesn’t seem very helpful with modern workflows..
Usually you don’t work on several separate projects, you work on one project and you switch branches depending on the feature that you are working on.
You can easily merge in your current branch the changes from another branch.
With the subprojects workflow how can you import the changes of another subproject considering that you are probably in the middle of the debugging or something else?
Smalltalk-80 -like "sub desktop-projects" are for smaller scale changes than "feature branches". They are about implementing different parts of a "feature" when that requires changes into several sub-modules.
I think "Mise-en-place" is really a good metaphor for it because you can arrange every tool-window you need for a given sub-task in a context dedicated solely for that sub-task. It is like in a kitchen you would have a separate "desktop" for preparing the meat and a separate one for creating the salad. They would need different tools around them, for easy access right?
A good example is implementing a client-server feature.
In the parent-task-desktop you are implementing client-side code that requests something from the server and then does something with the response it gets form the server. But the needed server-side function is missing, you must implement it too. Open a sub-project-desktop for working on that server feature. Open any editors and browsers and test-sets and change-lists and debuggers and spec-documents in that server sub-desktop. You can have similar windows in the parent client-desktop but those are totally separate from the windows you have opened in your sub-task-desktops.
It is easy to switch between the two back and forth which is often needed because when you change something in the server-part you may need to make a corresponding change in the client-part as well.
Or you discover a bug which is not about what you are working on now, but you realize it is best to fix it before doing anything else. Open a sub-project-desktop for fixing it. When you're done you get back to the exact same work-environment you were in when you discovered the bug and realized you better fix it right away.
On the desktop of Smalltalk Virtual Image you can right-click and say "New Project". This open a new window, which you can resize as you wish. Right-clicking on that allows you to "Enter Project". When you do you see a new desktop into which you can open various tool-windows, browsers, debuggers etc. And you can open nested project-windows inside a project-desktop, as deep as you wish. You can exit a (sub-) project but the (sub-)project still remains in existence, with its window in the parent-project as the handle to it.
As you exit your Smalltalk session you typically choose to "Save Image" which means this tree of projects, each having its own state and set of windows, perhaps a debugger halted on a piece of code, are saved with it. (You will see them the next time you re-open that same saved Smalltalk image).
When you're working on something you often discover that to do this you must first do something else. No problem, open a new "project" window on your current Smalltalk (project-) desktop. Once that sub-task is done you can exit that project and close its window. But you can have multiple (nested) sub-tasks open at the same time.
The name "project" is not the best word for them I think, I think they should be called "tasks". Why does that matter? Because I think it's important to understand that this is not about Project Management. This is Task Management. Something in the spirit of mise-en-place perhaps. You could create a Smalltalk image with tree of "project windows" on it and share it with your co-workers. These sub-projects could describe the subtasks and allow you to record you progress in them, say for cooking a specific type of dinner.
Smalltalk "project-windows" are such a great idea I wonder why something like them does not exist in other environments. No doubt having a "Virtual Machine" whose state is easily saved is a requirement.