Archive for the ‘Tasktop’ Category

Tasktop Dev 3.5 and Mylyn 3.11 Released

Monday, April 14th, 2014

Tasktop Dev 3.5 and Mylyn 3.11 are now available. These releases include some cool new features that result from the combined efforts of many people in the Mylyn community and at Tasktop.

Speaking as a Tasktop Dev and Mylyn user, I am already loving the new support for finding text in the task editor. It was originally contributed to Mylyn Incubator a few years ago, but unfortunately the implementation suffered from serious performance problems. Recently I had the pleasure of supervising a Co-op student at Tasktop, Lily Guo, as she reimplemented it with dramatically better performance and improved the UI. Thanks to her efforts this very useful feature is now released and the task editor supports searching for text within the comments, description, summary, and private notes.

Screnshot of Find in the Task Editor

Another long-awaited feature in this release is task-based breakpoint management, which extends the concept of task context to include Java breakpoints. This was implemented as part of a Google Summer of Code project by Sebastian Schmidt, a graduate student at Technical University Munich. It provides several important benefits for Java developers. First, the debugger will not stop at breakpoints that aren’t related to the active task. Second, only breakpoints created while the task was active will appear in the IDE – when working on a task, the breakpoints view and Java editors are no longer cluttered with dozens of irrelevant breakpoints. Because the breakpoints related to a task are only present while that task is active, there is no need to delete or disable these breakpoints – which often contain valuable information such as which lines of code and which runtime conditions trigger a defect – when a task is complete. Finally, breakpoints can be shared with other developers as part of task context.

Screenshot of the context preview page showing breakpoints in the context

In a single view, the Hudson/Jenkins connector provides quick access to status information about selected builds across multiple build servers, even when you are offline. This includes information about build status, build stability, and test failures. But one thing I realized was missing was a quick summary of how many builds are passing, unstable, and failing. This information is now displayed at the top of the Builds view and, when the view is minimized, in a tooltip, making it really easy to tell when there’s a change in the number of failing or unstable builds.

Screenshot of builds view showing summary of build statuses

This release also includes a number of bug fixes and enhancements to the Gerrit connector. Among them are support for comparing images, buttons for navigating to the next/previous inline comment in the compare editor, and a code review dashboard that lets you see which of your changes have been reviewed and whether they have passing or failing builds. The connector also remembers your previous votes on a patch set, so that posting additional comments doesn’t reset your vote. Thanks to Jacques Bouthillier and Guy Perron from Ericsson for their work on comment navigation and the dashboard.

Screenshot of the Code Review Dashboard

To help you prioritize the tasks you are responsible for, a “Show only my tasks” filter has been added to the task list, and the tooltip uses the gold person icon to accentuate those tasks.

Screenshot of the task list showing the new filter button

Tasktop Dev 3.5 is built on Mylyn 3.11, including all of the above features. This release includes a number of bug fixes as well as support for VersionOne 2013. We have also upgraded Tasktop Dev for Visual Studio to support Visual Studio 2013, bringing the benefits of a unified task list to users of that IDE.

For more information, see Tasktop Dev New & Noteworthy and Mylyn New & Noteworthy, or try out Tasktop Dev and Mylyn for yourself.

Watch Tasktop webinars

Tasktop Sync 3.5 released: VersionOne, Zendesk, links get sync

Tuesday, April 1st, 2014

We’re at the ALM Forum this week, where the hot topic is how to scale Agile and DevOps deployments.  What Scott Ambler made clear in his opening keynote is that there isn’t a single Agile best practice that spans the various sizes, domains, business processes that we find across organizations. While the practices and vendor tools implementing them vary greatly, the principles are consistent.  Short iterations, automation, real-time collaboration and end-to-end traceability are critical to an effective software lifecycle.  These principles are relatively easy for individual teams and startups to adopt.  The massive challenge that mid-size and large organizations are faced with is how to reap the benefits of Agile at scale.

While December’s Tasktop Sync 3.0 release extended our support to DevOps, the 3.5 release is all about supporting Agile at scale. Sync is now the lifecycle integration infrastructure for 5 of the top 25 world banks and powers many of the world’s largest Agile deployments.  The larger the scale of the deployment, the more problematic the disconnects between tools and processes become.  With Sync 3.5, we are introducing a new capability to our software lifecycle bus called Artifact Relationship Management.  This provides the last mile of integration needed for large scale Agile.  In addition to synchronizing the artifacts that make up your lifecycle, we now synchronize the relationships between those artifacts.  The result is end-to-end traceability and for best-of-breed and heterogeneous Agile deployments.  Which is pretty much every sizeable Agile deployment.

The internal workings of Artifact Relationship Management are complex due to the different kinds of relationships that make up your software lifecycle architecture.  For example, a requirement can be in a hierarchy, a folder, depend on an internal item or an external item, as well as being connected to tests, builds or source changes in other tools.  While it took 3 PhDs to untangle the various scenarios that enable Sync to federate relationships across tools, as with the rest of Sync, all of this functionality is now easy to configure for your administrators and completely transparent to your end users.  Whether you’re working with traditional requirements managements and Water-Scrum-Fall, or deploying new methodologies for large-sale Agile such as the Scaled Agile Framework (SAFe) or Disciplined Agile Delivery (DAD), you will now have end-to-end visibility, traceability, and collaboration across your best-of-breed tool stack.

RequirementsTraceabilitySLIpattern

We are also very pleased to announce Sync support for our partners VersionOne and Zendesk.  This means that we now have support for all of the market-leading Agile tools, and we have also made significant improvements to our support for Atlassian JIRA Agile, Bugzilla, CA Clarity Agile, IBM Rational Team Concert (RTC), Rally, Microsoft Team Foundation Server (TFS) and ThoughtWorks Mingle.  Adding to our other integrations, our Integration Factory is now continually testing 220 different versions of the Agile, ALM and DevOps tools that we support.

zendesk-versionone

Finally, Sync now has a new desktop and mobile device friendly Web UI. While Sync Studio provides the rich Eclipse-based configuration environment that allows Agile ALM tool administrators to easily deploy Sync purely through configuration, the Web UI provides you with a metrics of what Sync is doing, such as the number of synchronizations and artifact creations that are spanning systems.  Now that Sync has become a core part of the organizations’ Agile and DevOps infrastructure, these metrics provide a quick way to manage your Software Lifecycle Integration infrastructure as it evolves.

For more on the release, see New & Noteworthy

Watch Tasktop webinars

When it comes to Software Delivery, The E in Email Stands for Evil

Thursday, March 27th, 2014

Dr Evil - Photo courtesy of New Line Media Most organizations will experience failed software projects. They won’t necessarily crash and burn, but they will fail to deliver the value the customer wants. In other words, the software projects will not deliver an appropriate level of quality for the time and resources invested.

The extent of failed software projects is calculated every year in the Standish Chaos report– reporting software failure as 61% in 2013. There are many reasons for that kind of project failure rate. They range from poor requirements processes, to badly managed deployment, and a collection of other issues. Many authors have written about this, from the industry changing first work by Fred Brooks, The Mythical Man Month, to more recent works by the Agile and lean communities, but I don’t wish to re-hash these ideas here. I do, however, want to point out something that causes much trouble, pain and confusion in software projects– Email when used as a primary collaboration and process tool.

Imagine the following situation…

A tester discovers a bug, he documents this bug in his tool of choice (for this example, HP Quality Center), but because it is an important and interesting bug, he also sends an email to three developers who have worked with him on previous bugs. One of those developers replies directly to our tester with notes. The tester replies, adding a business analyst who is no longer involved in this app. Said analyst forwards the email to another business analyst who replies to the tester and yet another developer. The tester, business analyst and developers all agree on a solution, but the tester does not document this in Quality Center. That night, a CSV comes out of Quality Center and is converted into a spreadsheet by the project manager who allocates the bugs to the team. The special bug that the tester and colleagues were working on is allocated to a different developer, someone not involved in the email discussion. This developer talks to a whole different set of people to build a resolution. Sounds far-fetched? It’s not. I have seen much more complex communication networks created on projects. They resulted in confusion and a general disconnect between teams. And this issue is exacerbated across the departmental boundaries of QA, Dev, the PMO and operations because email is a poor way to collaborate. Why? because the “TO” and “CC” lists vary depending on whom the sender knows. And the original bug is just a memory by the 2nd or 3rd reply. Email isolates teams rather than uniting them. In fact, I would go one step further. If email has become one of the primary ways your project team collaborates/works, I would say email has become Evil, from a project success point of view.

To quote Wikipedia, ‘Evil, in its most general context, is taken as the absence of that which ascribed as being good.’ This description accurately describes email when it’s used to drive development, resolve issues or communicate progress. Most email begins with good intentions–adding additional people, replying out of your goodness of heart–but after the first few replies, it descends into layers of confusion, miscommunication and errors.

Email is evil because it:

  1. Does not automatically go to the right people
  2. Does not always include all the right information
  3. Is easy to drop and add new people, adding to confusion
  4. Is not stored, indexed or reference-able after the fact (unless you are the NSA, but that is a whole different blog post ;) )
  5. Holds no status or meta-data that allows for quick search or filtering

Maybe labeling email evil is a bit dramatic, but you get the idea. Email can easily, if not effectively managed, cause problems in your software projects. For that reason, we should reduce our reliance on using email to drive real work.

If you doubt your reliance on email, answer the following question: Can you stop using email for project related activities for one week and instead use your systems, processes and tools to get the work done?

If your answer is no, what can you do instead?

Ideally, use the tools you are meant to be using to manage the artifacts they are meant to manage. For example, a tester shouldn’t need to email anyone. The defects he identifies should be automatically visible to the right group of developers, project managers and fellow testers. Everyone should be able to collaborate on that defect in real time–with no need to send an email, or update a spreadsheet. In fact, testers and their developer colleagues should not have to leave the comfort of their tools of choice to manage their work. Comments, descriptions and status should be available to everyone in the tool they’re using.

Admittedly, the company I work for develops integration software. So I come from that world, but even if you build integrations yourself or use tools that are tightly integrated, the value of working in your tool of choice while the lifecycle is automatically managed through notification the correct people and capturing all collaboration in the context of one set of data, is massive. Miscommunication, misunderstanding and general disconnects among teams and disciplines have a huge and negative impact on projects. How many times have you thought a problem was resolved when it wasn’t because you were ‘out of the loop?’ We would find it unacceptable if our e-retailer or bank didn’t share information across processes, but we accept that our software delivery lifecycle is disconnected and relies on manual processes like email and spreadsheets. This problem is only made more acute with the adoption of Agile methods, lean thinking and dev-ops–movements that encourage smaller batch sizes, faster feedback and more team collaboration.

I encourage you to do two things:

  1. Measure the amount of time/work you are spending/doing in email
  2. Replace that with integration or use of common tools

It is time to use email for what it is intended, sending out happy hour notifications and deciding what pizza to buy at lunch.

Watch Tasktop webinars

Cheers from Tasktop Boston’s New Office!

Friday, September 27th, 2013

Finally Tasktop Boston has an office!

As a company in the “growth phase” Tasktop has remote employees all over the world, which is particularly beneficial in terms of our customer meetings, speaking engagements, and conference participation. Tasktop is pretty unique in that sense; we are able to pursue numerous international opportunities even though we are only a company of about 60 people. But we are at the point where we are starting to think about which of our remote locations makes the most sense for brick-and-mortar expansion.

Boston was a pretty obvious choice for several reasons. While we are headquartered in Vancouver, many of our customers are on Eastern Standard Time. Here we are also able to act as the “middle time zone” if you will, for our colleagues and customers in Europe. Boston is also known for its association with start-ups and tech companies. It is a unique environment; the city and suburbs are very supportive of small companies’ growth, and local employees tend to be ambitious and energetic and definitely practice the “work hard, play hard” mentality.  Based off that alone, Boston was a perfect cultural fit for our small company! We’ve grown to four employees out here in the past year. We are not a big group (yet), but with that kind of growth, I’m sure there will be more Boston Tasktopians soon!


The “office location courtship” was a unique process for me. Every office looked GREAT on paper, and when heading over for each building tour, I found myself hoping that this would be “the one” so that we could set our roots down somewhere!  I quickly realized that no office was going to be the perfect space I had pictured in my mind.  We weighed the pros and cons and learned what qualities we could and couldn’t live without. Tasktop is a pretty social company, so we wanted to be in an office with a lot of activity, and being in the midst of other start-ups would be ideal.  With some help from the City Economic Development Department, we finally found a location that fit our needs well and signed on space in the Alewife section of Cambridge, Massachusetts. Sure, we had to give up the glamour and prestige of a Harvard, Kendall, or Back Bay address. But we are still extremely close to the city and are in a brand new office, a beautiful space to call our own, and that’s all we need! Alewife is definitely an up-and-coming area, especially for tech companies, so we look forward to seeing how the area changes as the construction projects progress! Who knows, maybe we’ll look back in ten years and think, “We were working at Alewife before it was the cool place to be!”

Day One at the office was last Monday, and we moved in so seamlessly that Betty, our VP of Marketing, remarked, “I’m worried because this was just too easy.” Sure enough, on Day Two we realized that we were going to have some serious kinks with our internet. I don’t come from an IT background, but let’s just say that I’ve become pretty well-informed on internet speeds and what will and will not make you a fully-functioning employee.  We (hopefully) solved the problem earlier this week, and we are quite relieved to be able to resume business as usual.

Dave, Betty, Kristie, and Katelyn celebrate the opening of our newest office

Several “firsts” in the new office were particularly exciting for me: our first All-Company meeting in the same room together, and our first Happy Hour! Our colleagues were so excited to get the video tour and see pictures of our new space.  Tasktopians are serious team players, so I was often asked for updates on how the office search was going for us.  They are so thrilled that we were able to find such a great office space and are interested to see how we make it our own as we get comfortable. In true Tasktopian champagne-toasting fashion, we celebrated our first Happy Hour at the conclusion of our first successful week in the office.  I always look forward to these get-togethers with my colleagues because they provide a different environment to get to know each other outside of working hours.  Of course it was the highlight of my week!

I’m so happy to finally be in an office with my coworkers. I can say with absolute sincerity that I have established some great friendships with my colleagues in Vancouver and not many people can say that they have made connections like that over video conferencing alone! But after working from home for almost a year, I am thrilled to see what bigger and better things we can accomplish while sitting side by side. Tasktop Boston is about to take over the world, and you’re hearing it here first!

Watch Tasktop webinars

Enjoy more integration options with Tasktop Dev 2.8

Tuesday, September 3rd, 2013

Tasktop Dev 2.8 was released on August 8 and has several interesting enhancements to note.

This release introduces new capabilities that leverage Tasktop Sync to provide new SCM traceability capabilities across disparate tools. Imagine ACME co. has a development team that has adopted HP ALM. They’ve also adopted HP Application Lifecycle Intelligence (ALI) which includes SCM integration and Tasktop Dev (OEM’d by HP as HP ALI Dev). When ACME’s developers commit code, ALI provides full traceability between the code and defects or requirements managed with HP ALM. All is well with the world until ACME acquires a subsidiary that uses JIRA and wants to integrate it into ACME’s existing infrastructure. Now, code committed against JIRA issues is no longer visible in HP ALI reports, wreaking havoc on the unified visibility and reporting ACME had been getting from ALI.

Commit Traceability

Not to worry, ACME can restore order with Tasktop Dev 2.8 working in concert with Tasktop Sync. By synchronizing HP ALM with JIRA, each JIRA issue becomes associated with a corresponding HP defect or requirement. When committing code against a JIRA issue, Tasktop Dev 2.8 automatically inserts the corresponding HP ID into the commit message. This establishes the link between the code and the HP artifact, thereby restoring the HP ALI traceability and reporting ACME had come to rely on.

Other key improvements for Tasktop Dev 2.8 include support for Tasktop trims in Eclipse 4 such as the working set trim, web search, starred list and task timing counter.

E4 Trims

With the Gmail Connector, developers can bring messages with a given label into the integrated Task List, providing a single “inbox” that unifies both email and incoming notifications from ALM systems. For Tasktop Dev 2.8 the Gmail integration has been enhanced with the ability to jump from a given point in a Gmail message thread in the IDE to the corresponding expanded message in the browser where the full Gmail functionality is available.

Check out Tasktop Dev 2.8 or contact us about the cross-ALM source code traceability feature which is currently available as part of an Early Access release.

Watch Tasktop webinars

Agile 2013 Retrospective

Wednesday, August 21st, 2013

… or, “work isn’t supposed to be this much fun”

I’m just about recovered from our whirlwind trip to Nashville for the Agile Alliance’s conference Agile2013. There were 1700 attendees, 200 sessions, keynotes, parties, and a little controversy.

On a personal note, I was gratified to see the number of women in technology there… most specifically, the number of women who gave talks. Encouraging women to take leadership roles in technology is a side project of mine – I help run a blog and mentoring program at ALineAtTheLadiesRoom.org.

So for me personally, Agile2013 was a blast!

I bumped into so many people I know from various “former lives” – a former engineering manager, a former engineering colleague… folks I know from Agile New England – as well as hanging out with my colleagues at Tasktop (into the wee hours of the morning :-) ).

It was also terrific to meet Tasktop partners, customers and prospective customers. I had the opportunity to spend a bit of time in our booth, chatting with people who often started the conversation with, “My friend told me I had to stop by your booth. Can you really integrate <product A> with <product B>? We’ve got so many systems that don’t talk to each other and… “

This kind of conversation is HUGE fun for me; I haven’t cut code, fixed bugs or managed a software deployment in a while, but still love helping those that do.

Mik presenting

Mik delivering his session

I also had great time listening to Tasktopians give their talks. Mik Kersten, Tasktop’s CEO presented: “As distributed as it gets: 10 Agile best practices from open source” and Dave West, our Chief Product Officer presented: “Agile ALM – A horror/feel good/fantasy story“. Check out their slides; unfortunately it’s not like hearing the talk itself because both Mik and Dave are such great speakers. (If you create an account on tasktop.com, we’ll put you on our mailing list so you can find out about our upcoming talks and webinars).

And while it’s not the same as hearing his talk, you can hear a bit of Dave’s perspectives in two video interviews that were done at Agile. One by DZone and one from BigVisible.

While at Agile, Tasktop made a couple of announcements. On Monday, we announced our partnership with Serena, and on Tuesday we announced the GA of Tasktop Sync 2.8. Our CEO Mik blogged about this release, time tracking and how we’ve connected the worlds of Agile ALM and Project Portfolio Management (PPM)… it’s definitely worth a read.

So, were you at Agile2013? What was notable for you?

Watch Tasktop webinars

Tasktop 2.8 released, Serena partnership announced, death to timesheets

Tuesday, August 6th, 2013

Filling out time sheets is about as fulfilling as doing taxes. This mind-numbing activity is an interesting symptom of what’s broken with the way we deliver software today. What’s worse than the time wasted filling them out is the fact that the numbers we fill out are largely fictitious, as we have no hope of accurately recalling where time went over a course of a week, given that we’re switching tasks over a dozen times an hour. As Peter Drucker stated:

Even in total darkness, most people retain their sense of space. But even with the lights on, a few hours in a sealed room render most people incapable of estimating how much time has elapsed. They are as likely to underrate grossly the time spent in the room as to overrate it grossly. If we rely on our memory, therefore, we do not know how much time has been spent. (Peter Drucker. The Essential Drucker, ch. 16. Know your Time)

Tracking time is not a problem. When done well it’s a very good thing, given that time is our most scarce resource. Done right, time tracking allows us to have some sense for what the burn downs on our sprints are, and to predict what we will deliver and when. It allows us to get better at what we do by eliminating wasteful activities from our day, such as sitting and watching a VM boot up or an update install.

Effective knowledge workers, in my observation, do not start with their tasks. They start with their time. And they do not start out with planning. They start out by finding where their time actually goes. (Effective Drucker, ch 16. Know your Time) (Peter Drucker. The Essential Drucker, ch. 16. Know your Time)

Drucker was a big advocate of time tracking systems for individuals. With Agile, we have now learned how effective tracking story points and actuals can be for Scrum teams. Yet all of this goodness feels very distant when the last thing that stands between you and Friday drinks is a time sheet.

What we need is a way to combine the benefits of personal and team-level time tracking with those needed by the Project Management Office (PMO). With the Automatic Time Tracking feature of Tasktop Dev (screenshot below), we validated a way to combine personal time tracking with team estimation and planning. I still use this feature regularly to be a good student of Drucker and figure out where my own time goes, and many Scrum teams use it to remove the tedious process of manually tracking time per task.

While that automation is useful for the individual and the team, it did not help the PMO, that works at the program, enterprise and product level. PMOs use specialized project and portfolio management software such as CA Clarity PPM. So now, in our ongoing effort to create an infrastructure that connects all aspects of software delivery and to keep people coding and planning to their hearts’ content, we have stepped out of the IDE in order to bridge the divide between the PMO and Agile teams.

The Tasktop Sync 2.8 release includes updates to the leading Agile tools, such as support for RTC 4, HP ALM, CA Clarity Agile and Microsoft TFS 2012. It also ships the first Sync support for Rally and the TFS 2013 beta. The other big news is that we now are announcing a partnership with Serena in which both Tasktop Sync and Tasktop Dev will be OEM’d as part of the Serena Business Manager lifecycle suite. This new integration, which further cements Tasktop’s role as the Switzerland of ALM, will be showcased at Serena xChange in September, and ship this fall.

With Tasktop Sync 2.8, we have finally managed to connect the worlds of Agile ALM and PPM both in terms of task flow, and time reporting. While the support currently works for CA Clarity only, integrating these two worlds has a been a major feat in terms of understanding the data model and building out the integration architecture for connecting “below the line” and “above the line” planning (Forrester Wave). For the individual, it’s like having your own administrative assistant standing over your shoulder filling out the PPM tool for you, only less annoying and easier to edit after the fact. For the Agilistas, it’s about getting to use the methods that make your teams productive while making the PMO happy. And for the organization, it’s the key enabler for something that Drucker would have been proud of: automating the connection between strategy and execution.

Watch Tasktop webinars

Betty Zakheim: “All Roads Lead to Tasktop”

Thursday, July 18th, 2013

Tasktop is connecting the world of software delivery – now that was an opportunity I just couldn’t refuse!

I’m really excited to have joined Tasktop. The company’s mission and products are near and dear to my heart, and I’m so pleased to be working with such a talented, dedicated and genuinely nice group of people.

It’s interesting though, that as I think back on the roadmap of my career, it seems that all roads led me to Tasktop; it’s just that until just a few weeks ago, I didn’t realize it.

Of course I was aware of Tasktop; the company is widely known for its ALM integration tools and platforms and, most recently, the introduction of the Software Lifecycle Integration framework. But for me, it was more than just awareness, it was admiration. As a former UX developer, I found the “task-focused interface” work of co-founder and CEO Dr. Mik Kersten very intellectually stimulating. As a former software engineer and engineering manager, I have to love a company that removes some of the process tedium from daily life, while making the whole team more efficient. And, as a (fairly) savvy business person, I love the idea that we’re not competing against the leaders in Application Lifecycle Management – our goal is to help everyone be more successful.

In my opinion, if you’ve ever worked on a software development team that was hindered by your colleagues working in silos, you have to admire Tasktop.

But the confluence didn’t stop at admiration.

I’ve been at this “software development” thing for, um, a while. I’ve had the pleasure of working at some truly innovative companies, and (with a tinge of modesty), being a bit of an innovator myself. So as I look at what Tasktop brings to the party, and I recount my own experiences, being called on to lead Tasktop’s marketing team feels like it was almost inevitable.

I started in technology as an engineer. I’m a bone fide, diploma-carrying computer engineer/computer scientist. My first roles were in what was then called “human factors,” but we now call User Experience. I worked on all sorts of interesting systems, from radar and air traffic control to quality management software for systems that test printed circuit boards and (in my last coding role) workflow or what’s now known as “Business Process Management” (BPM).

Eventually, I became the VP of Marketing and Product Management at that BPM company, InConcert (a spinout of Xerox research), where pivoted to use our workflow product as a way to integrate disparate systems. We initially concentrated on the telecommunications industry, because in 1996 deregulation led to a flurry of new telecoms companies that relied on each other (and each other’s systems) to operate.  The first business process we tackled was “service activation,” the process of establishing a customer’s account. At each step of the process (or task), we wrote “agents” to connect to the various systems needed to complete that step. It worked well, got terrific acceptance and eventually TIBCO software bought the company.

But the thing that always bothered me was how hard it was to write those agents. Back then, CORBA was the leading technology for this sort of thing.  Yes, tightly-coupled CORBA!

Fast-forward a few more years, and I had the opportunity to work at IONA (yes, the CORBA company!), when the up-and-coming technology was web services.  Going from being tightly coupled to loosely coupled was, without question, the way to go for integration technology. IONA adopted web services as an integration technology, and I had the pleasure of bringing those products to market.

When I left IONA, I left the world of integration technologies for a while. But I continued to work on products for software developers. In fact, one of my favorite jobs was with Rational Software.

Back then, Rational Software was an independent company and the leader in cross-platform software development tools. As a director, I was proud to lead all aspects of marketing for ClearCase and ClearQuest. Once IBM acquired us, I lead all product, industry and solutions marketing for the entire Rational Brand. While Rational itself was a substantial software company (around $800 million in revenue a year), I learned quite a bit about enterprise scale after joining IBM! Not only were our customers some of the largest in the world, but we were part of a very large company.

After IBM/Rational, I worked at few other notable development tools companies such as Progress Software and, most recently, SmartBear software.

In between all those jobs, I started my own consulting company, and it shouldn’t be a surprise that many of my clients catered to software development teams. I’ve had all sorts of roles: software engineer, engineering manager, consulting engineer, product manager, and now joining Tasktop; this will be my third company where I’ve been at the helm of the marketing team as VP of Marketing.

The role at Tasktop is a wonderful confluence of several things I hold near and dear: advancing the state of the art of software development and delivery, the integration of disparate systems and delivering a terrific user experience.

I couldn’t be more excited to be part of a team and a company that is so well positioned to make such a substantive difference is the software development and delivery process – and to do our part to change the world through better software.

Watch Tasktop webinars

Viva Eclipse Kepler!

Monday, July 15th, 2013

Say what? Another Eclipse DemoCamp at Tasktop? That’s right, and it was something to brag about! Tasktop Technologies, the Eclipse Foundation, and Pivotal hosted Eclipse Kepler DemoCamp at Tasktop HQ in downtown Vancouver for Eclipse enthusiasts, faculty and students who work with the Eclipse IDE.

The evening began with networking and snacks. We opted for delectable aliments doigt, with fine cheeses, le sandwiches, stuffed mushrooms and seafood, instead of pizza and pop that has become the staple food of many a developer (not you, of course, we know you have a more sophisticated palate).

David Green and Andrew Eisenberg then kicked off the evening with event intros and warm welcomes…

…followed by an icebreaker game…

This year, we played Big Data, where each participant was asked to gather data about other attendees. We thoroughly enjoyed it, maybe because we’re all geeks.

After the game, the data was collected and collated. It is now ready to be map-reduced by Hadoop. Here are the resulting statistics of the make-up of this year’s DemoCamp participants:

Yes No
Attended EclipseCon? 6 31
Commiter? 8 16
Student? 10 19
Created plugin? 21 9
Raised a bug? 8 7
Contributed? 10 13
Program daily? 40 5
Java? 21 8
IntelliJ? 0 29
Netbeans? 0.5 47
CS degree? 16 4

Note: these results reflect the skills of first time data-collectors (ie: numbers may not approximate reality).

…with all the attendees warmed up and well fed, the presentations followed…

David Green (Tasktop) Showed off the new super-secret tooling in Eclipse for working with GitHub.

Nieraj Singh and Kris De Volder (Pivotal) showed some of the new features of Spring Tool Suite 3.3.0, including the new Quick search feature and getting started guides.

Rafael Chaves (Abstratt) presented Cloudifier, a platform for rapid application development/deployment built on Eclipse Orion.

Deepak Azad (UBC) demoed new features in Eclipse JDT for the Kepler release, mostly new quick fixes and null type inferencing improvements.

Robin Salkeld (UBC) introduced holographic JVMs and a way to debug Java heap dumps. His technique allows you to attach a Java debugger to a heap dump and then execute queries against it using the Java debug interface.

Brendan Cleary (UVic Chisel) showed off Atlantis, which is a file viewer for massively huge files (60 Gb+). He described how Atlantis is used by the Canadian government for analyzing trace files to look for potential security breaches.

After the last presentation, everyone headed out for drinks to celebrate another successful Eclipse DemoCamp. Cheers!


AndrewA warm thank you must got out to Andrew Eisenberg for co-authoring this blog, as well as to all other organizers, sponsors and speakers who contributed their time and energy to making this event a success. If you’d like to be a speaker during a future Eclipse DemoCamp, please contact us. It’s a wonderful opportunity to show your stuff in a supportive circle of other Eclipse enthusiasts and have some fun while you’re at it. See you all next year!

Watch Tasktop webinars

It Takes A Village … Business Analysts: The Unsung Heroes

Monday, July 8th, 2013

Over the course of my career I’ve seen a lot of teams structured in a lot of different ways using a lot of different methodologies. But the ones that were successful always had one thing in common … a deep understanding that there are a variety of roles that have to be in place to deliver great software products to customers. My motto … it takes a village to deliver great products!

The Business Analyst is one of the roles that often is under-appreciated but can deliver significant benefits. I’ve always wondered why that is the case. After all, the goal is to keep your developers and testers focused on what they’re there for – coding “magical things” – but you need to make sure they code the right “magical things”! Business analysts are, in my opinion, the unsung heroes who do just that.

It takes a unique combination of skills to effectively capture the needs of your customers and creatively translate those needs into what to add to or change about your product. When a BA successfully does, they are essentially handing to the developers the proverbial “silver platter” – the developers can then “work their magic” using their creativity and innovation to bring those needs to life.

You may be thinking … “Really? Even for back-end integration software? Shouldn’t dev teams know what to build innately?“ Ironically, we see the value of business analysis even more for technically difficult and largely “under the covers” software like ours. Precisely because it is so technical and behind the scenes we find it is even easier to get lost in the weeds and code the wrong “magical things” or code the “magical things” incorrectly or with short sightedness. If we deliver a great technical solution but forget to meet the use case our customers need, that great technical solution doesn’t really matter.

One part UN Ambassador, one part translator, one part designer, one part information organizer – the role itself is fabulously varied and requires a very broad skill set. If you tried to map out a day in the life of a business analyst, I’m not sure you could because the days are so different!

Here at Tasktop, we take the “it takes a village” motto very seriously as we believe that by recognizing the different skills sets and contributions each of the different roles brings, we maintain our competitive edge – and deliver better product to our customers. To that end, we are expanding our team of business analysts. Check out our job description- join our village and help us build the right “magical things”.

Watch Tasktop webinars