We’ve been using Teamworks 6.x for 15 months now.  The pros and cons of TW compared to traditional .NET / web development are becoming clearer.

Pros:

Our business processes are visible and understoon by the right people.   This is huge!  We now have the flexibility to change the way we do business.  TW provides a visual common domain-based representation that a non-developer can understand.  It provides a frame of reference that helps Subject Mater Experts (SME) and Developers discuss the things that are important and aids them in making decisions that effects our organizations productivity.  Since using Teamworks to implement our processes, we’ve managed to eliminate waste and productivity has gone way up.  And we only expect things to get better.

Teamworks has lots of Business Analysis tools.  I’m not an expert in this area but I can tell there are lots of built-in utilities that we didn’t have to develop ourselves.  Examples include process variable searches, KPIs, SLAs, and a bunch of other stuff I don’t understand.  I don’t know what they do, but I know they get used and I didn’t have to spend 1 minute writing any of them.

Teamworks is collabrative.  Business Analysts can build out the UI (with a little assistance) and the processes.  The work is shared; developers don’t have to do it all.  And documentation can be added everywhere so (if used appropriately) it replaces design documents that have a tendancy to fall out-of-date.

 

Cons:

Traditional software development Best Practices are immature or unavailable.  Unit Testing?  Source Control?  Change management?  Continuous Integration?  Refactoring tools? Nope.  Not here.

Processes are extremely brittle.  Being able to visually represents the process makes you think it is easy to change but lack of refactoring tools makes it very hard to change correctly.  Everytime we have a semi-major deployment, we expect something to break (and fail a bunch of process).  When we were deploying traditional .NET web applications, these kinds of catostrophic failures were unheard of.  We can usually get the problems fixed in short order but our credibility has still suffered.

Development is slower and incurs more strain.  Ask any good data-entry person and they can tell you that entering info using the keyboard is faster than using the mouse.  TW relies heavily on mousing and switching windows and clicking on stuff and waiting for the GUI to change (and hope it doesn’t decide to just close down instead).  Everything good and convenient about using your keyboard and a text editor is MIA.

Code is less visibile.  Even though the process is visible, the code behind it is not.  Code inside a process can only be viewed piecemeal.  (Each code snippet is hidden inside different process componets).  Try to search everything or refactor something that is used many places and you are out of luck.

 

In Conclusion

You’re Developers won’t be doing any happy dances that they get to work in Teamworks BUT your business and bottom line should really see an improvement in its day-to-day productivity.