Is there a Workflow tool that increases productivity

Question

We have been developing a workflow based .net web application for the last two months, my team had been working like donkeys. Its almost complete and we are sure of getting the next project from the client. My project manager went for some workflow product demo (K2), came back and asked me:

What tool you wish you had to increase your productivity ?

I looked at him with a dumb face as I hadd no clue how we could have squeezed more work out of our tight timeline.

I wonder is there a workflow tool for an average developer that can actualy increase productivity

Answer 1

Ask how he defines productivity :

More code? Better code? How? Less bugs etc etc

Answer 2

'No Silver Bullet' was the title of an essay by Fredrick Brooks in which he states a point that software development is inherently complex and there is no tool that will take away that complexity and turn it into a mechanical process.

Workflow tools with a graphical interface tend to be slow to program and do a poor job of managing complexity - typically much poorer than a programming language. This issue also applies to ETL tools and transactional integration tools such as BizTalk or WebSphere Integrator. Practically, this means that implementing complex business logic in a workflow tool tends to be quite long winded and often difficult to test.

K2 is probably as good as any workflow tool and is based on Sharepoint, so it will play nicely with software written on a Microsoft stack. It may give you a productivity win over raw MS workflow foundation, but I doubt it will be a silver bullet.

For a wish list, I suggest moving towards a tool chain that facilitates architectures that are easy to automatically test. Manually testing workflow based apps as a developer is tedious and quite time consuming. Finding a way to script the tests will be a win.

Answer 3

The tools I use for productivity are:

1. A Tomato Timer
2. A pencil
3. Some Paper

Try out the Pomodoro Technique

Answer 4

It's low tech, but for each task I work on, I keep a text document open which describes the task I'm working on, the next actions, the actions I'm waiting on for other people, any assumptions I've made along the way, my test plan, and any other notes I made.

I find that this keeps me on track, let's me recover from interruptions faster, and forces me to think through the issue more clearly than keeping all this in my head. The result is time savings and better work/testing.

For example:

Issue 57833
Assumptions:
- The import should fail on condition X
- Customer Y doesn't use the import

Next Actions:
[X] Get clarification or screenshot
( ) Waiting on account manager to get me the import file
[ ] Reproduce the bug
[ ] ...
[ ] ...

Tasks:
[X] Fix loop conditions in blah::method
[ ] Update config for customer A
[ ] Update config for customer B
[ ] Testing

Testing:
[ ] Import file with problem X; import correctly failed and reported X
[ ] Import file with problem Y; import correctly failed and reported Y
[ ] Added unit tests

Notes:
Using user 5323 to reproduce bug