Waterloo Region Infographic

This week we have another great infographic. This time about PMRobot's hometown -- Waterloo, Ontario, Canada.

Sortable has put together some great stats about the region:

You can click the graphic for the original article at Sortable.

New: Clean and simple navigation

PMRobot has a great new menu and navigation system!

We've always had the most features, but sometimes it's been a bit difficult to actually find them. :)

Those days are over.

Everything is now right at your fingertips.

We've crunched through over a year of logs and statistics to determine the most frequently used pages, and put them right up front.

The less popular (but equally useful) pages have been moved to a secondary menu.

They're still easy to access, but don't get in the way of your day-to-day work.

We've also improved the "quick submit" box by moving it to the left and sprucing it up:

...and don't forget -- PMRobot works great on mobile devices like smartphones and tablets!

We hope these improvements help save you even more time, and make your day just a bit more pleasant :)

We're continuing to work hard every day to make PMRobot faster and easier for you.

What do you think of the new navigation?

Where will your software be in 20 years?

When creating software these days, people mostly think 1, 2, maybe 3 years out.

I recently touched based on a job costing program I wrote in C++ when I was 16 (and re-wrote as a client-server app in Java/MySQL) that is still being used on a daily basis.

That's nearly two decades of active service!

And if you think about it, there's still quite a lot of software from that era still kicking around: Windows, Word, Excel, BSD, Linux, Photoshop, and many others.

There's fad software, and there are programs built to adapt, and stand the test of time.

Photoshop today is certainly more advanced than the first version released in 1990, but the core principles remain the same.

Successful software products must constantly evolve to suit an ever-changing environment.

It's easy to get caught up in day-to-day bugs and support requests, but it pays to stand back and take a broader view every so often, thinking about the long term.

So -- Where will your software be in 20 years?

The history of issue tracking systems

Web-based issue tracking systems (often referred to as "bug tracking" systems) have been around for a long time. Let's take a trip down memory lane and review issue tracking software to date.

1998 - Bugzilla

Bugzilla is arguably the great-grandfather of all web-based bug tracking systems. Written in Perl in 1998, and still in active use today, it defined a lot of conventions used by the systems that followed.

A bug in the basic Bugzilla workflow can be in one of the following states:

1. Unconfirmed
2. New
3. Assigned
4. Resolved
5. Reopened
6. Verified
7. Closed

Bugs can transition between these states in a number of standard ways. For example, when a developer completes work on a bug, it moves from Assigned to Resolved. A quality assurance (QA) person then tests and can put the bug into the Verified state if the developer's fix is confirmed.

This workflow has remained largely unchanged over the years.

In addition to bugs, Bugzilla allows "tickets" to track and prioritize feature requests in the same database.

2000 - Mantis Bug Tracker

Started in 2000, but not reaching version 1.0 until 2006, Mantis Bug Tracker (or "MantisBT") is a popular open source bug tracker written in PHP.

It introduced a much nicer user interface than Bugzilla, and offered more customization, including customization of the bug workflow and state transitions.

Although primarily meant for open source projects, Mantis is a very capable system. We used it for several years at Syllogistic Software prior to development of PMRobot.

2003 - JIRA

JIRA, a commercial product launched in 2003 and built in Java, represented another step forward for issue tracking systems, adding additional customization options, and a powerful plugin architecture.

In addition to issue tracking, Atlassian offers a number of products that integrate with JIRA to help with project management, documentation, and source control integration.

The JIRA platform tends to work best for large enterprise software projects.

2006 - Trac and Redmine

In 2006, two similar projects were born: Trac and Redmine. Both are open-source project management and issue tracking systems. Both offer web-based ticketing system similar to Mantis, along with support for milestones, Wiki-style documentation, and source integration.

Trac is written in Python (a language favored by Google), whereas Redmine was developed on the recently popular Ruby on Rails framework.

Both systems have a multitude of functionality, but their user interfaces can be confusing for beginners or non-technical users. They are targeted towards open source projects, or other highly technical teams.

2008 - Pivotal Tracker

Although it focuses more on agile feature tracking than issue tracking, Pivotal Tracker introduced a number of innovative user interface enhancements.

Its extensive use of multi-column drag and drop allows quick reordering of "stories" (similar to tickets). The UI also allows for one-click transitions between states with buttons such as "Finish", "Accept" and "Reject" easily accessible on the main story list.

Using Pivotal requires a through understanding of the Agile Methodology, and is best suited for organizations that have fully adopted it. The software uses many Agile terms in the interface, and assumes that your process mirrors the built-in states.

It is best suited for organizations that have a stable, fixed team working on long-term projects. Otherwise the "story point" estimation methodology, and overall workflow, tends not to work well.

2012 - What's next?

It's been nearly four years since the last major innovation in issue tracking.

We're seeing a lot of action in the mobile world, but mostly iOS and Android applications to access existing issue tracking systems.

What's the next big thing in issue tracking? Let us know in the comments below.

PMRobot Google+ Hangout

Just a quick little note that this Wednesday, December 14th at 11:00am Eastern, we'll be hosting a Google+ Hangout to chat about the latest PMRobot release.

Put PMRobot in your Google+ circles and join us to learn and give your feedback.

In the meantime, check out our new front page video explaining how PMRobot is the best all-in-one solution for software consultants!

Eating your own dog food

There's an odd term in the software industry called "eating your own dog food."

Microsoft coined this term in the late 80s.

The main idea is that companies that make a product should use that product on a daily basis. That way, you can experience the pleasure (or pain) yourself, and have a better idea of where to focus resources.

At PMRobot, we use our own software every day.

It was conceived and born in our sister company, Syllogistic Software, and continues a core element of our processes.

"Dogfooding," as its often referred to, is absolutely essential when building a product, because it really helps motivate internal innovation, and quick fixes to problems.

A similar example, dating all the way back to 1981, is when Apple decreed in a memo:

“EFFECTIVE IMMEDIATELY!! NO MORE TYPEWRITERS ARE TO BE PURCHASED, LEASED, etc., etc. Apple is an innovative company. We must believe and lead in all areas. If word processing is so neat, then let's all use it! Goal: by 1-1-81, NO typewriters at Apple... We believe the typewriter is obsolete. Let's prove it inside before we try and convince our customers.” - An Apple On Every Desk

If an annoying change makes it to the server, we experience the pain first hand, instead of just hearing a second hand account from our customers.

If you develop a product, consider making daily use of that product a habit.

I guarantee it will help you produce something of much higher quality.

Boomerang for Gmail Review

As a "follow-up" to Ramy's article about FollowUpThen, I wanted to share my favorite email follow-up service -- Boomerang for Gmail by Baydin.

I've been using it since early beta, and it has become a powerful tool in my email productivity arsenal.

It's basically a snooze button for your email, and integrates right into the familiar Gmail interface.

At $50/year for a personal account, and $150/year for a professional account, it's not cheap compared to Gmail itself.

However, it works very well, is extremely reliable, and could end up being worth the money for someone who sends and receives ridiculous amounts of email. (like yours truly :)

The feature is use most is the basic "Boomerang incoming" functionality. Just tell Boomerang when you want the email to come back (tomorrow 8am, next thursday, etc.) and it disappears and is redelivered at that time.

For power users, here's an example of a more complicated workflow:

1. You receive an email from Bob asking whether you can meet up next Friday, but you have a tentative meeting scheduled with Mary.
2. You send an email to Mary asking if the meeting is still on, but click the "Boomerang this message if I don't hear back in 2 days" checkbox.
3. If Mary responds promptly, nothing happens.
4. However, if Mary does not reply, Boomerang puts the message back in your Inbox so you can re-ask her, or perhaps give a call or text.

Another feature I use often is the Send Later feature, which is similar to Outlook's Delay Delivery.

I sometimes find myself working at odd hours -- 2am, 3am -- and need to send various emails, like invoices, updates, etc.

Sometimes it might be consider a bit rude to send emails in the middle of the night. What if the recipient forgot to turn off their Blackberry and it buzzes and wakes them up?

I simply draft up the email, press Save, and then use Boomerang's Send Later button. A dropdown lets me specify when (usually "tomorrow morning").

In summary, Boomerang for Gmail is a nicely implemented service that does a great job of filling a void in Gmail's functionality.

Kudos to the folks at Baydin!

Forget Flagging Emails - Follow Up Then

I've recently been introduced to a great tool that's helped me in managing projects and fits perfectly into my personal workflow of how I deal with emails and keep on top of things where I need to make sure some action gets taken.

In the past, I flagged emails. First in Outlook and then a few years later using "Stars" in Gmail. It works pretty well. After I sent an email, if I wanted to make sure that the person that I sent the email to actually did something with it, I would go into my sent items folder and Star the email. Once a week or so, I would cycle through my Starred items and see if there were any messages I needed to follow up on…

Enter Followupthen.com. Before I go on. I don't know the people who developed this product and I have no affiliation with them other than being a big fan of their service!

Basically, you can send an email to 1week@followupthen.com, 3hours@followupthen.com, nextmonth@followupthen.com or any other description of time you can think of. After that set amount of time, you'll get a reply/forward from Followupthen (with the same subject line so that message threading works correctly) which basically brings that conversation right back into your inbox.

There's a few reasons I like this. But before that, I'll illustrate the two different ways that I use this service.

If I'm sending an email and I want to basically remind myself to follow up a week later (if I don't hear back from the recipient) it's as easy as BCCing 1week@followupthen.com. No extra action is required. I don't need to look up the email after sending it and mark it. The recipient has no idea about it and I can feel confident that if I don't hear back in a week, that email conversation will magically pop back into my inbox for me to follow up on.

The other way I've used the service is when I receive an email that I don't necessarily want to write back to immediately. Whether it's a good practice or not, I'm a big fan of a clean inbox. So when I get those emails, if I want to remind myself to reply 2 days later, I simply forward it to 2days@followupthen.com and then archive it. Again, it fits right into my workflow, which is what makes the service so useful.

The one downside or questionable part of this is that I am sending some of my emails to this service. I'm careful that nothing with even the mildest amount of confidentiality goes out this way. That being said, considering that Google and Apple basically own most of my information anyway, it's probably not too big of a deal.

Finally, aside from actually using the service, it's also been a good learning for me in terms of creating meaningful business solutions. The service is simple. It does one thing. And it does that thing well. The most important part for me is that it fits into my workflow and as a result, it was really quick to adapt to.

We are taking this lesson into account as we continue to improve PMRobot and looking closely at the workflow of project managers and software developers to ensure that PMRobot slips right into the way most people are working already! Have feedback about how we can improve PMRobot from a workflow point of view? Drop me a line at ramy@pmrobot.com.