Thoughts on Raven so Far

The black art of software development is shrouded with geek-speak, bumped (read:missed) deadlines, over-budgetness and tens of thousands of lines of code that very few can appreciate the beauty of. I'm hoping to write a few words every week to keep focused on the tasks central to the success of this project.

Raven.HelpDesk

The first few bits in the Raven HelpDesk have been delivered for feedback to the the HelpDesk staff. It was well received and though not terribly functional, it has ensured that our environment is configured and they have everything they need to run the app. They are also now in the feedback loop to help establish features and process changes.

TheNextMostImportantThing

The idea on an agile project is that we're trying to get bang for the buck, continuously delivering what serves the company where it is needed most. Bang comes in two forms: saving money and making money. Which is really the same thing. Since the large part of development on Raven is internal, this means we are looking at the 'saving' side of the equation.

My goal is to be delivering a NextMostImportantThing every week. Some things will be more visible than others, some things will require process changes or new processes. With co-operation and guidance from co-workers, these will all move us to greater profitability, proficient staff, efficient software and better productivity.

Here are the five NextMostImportantThings in my queue (also referred to as Customer Stories):

1. Identify Customer - Automated through Asterisk
2. Create and reopen work tickets
3. Assign and view assigned tickets
4. Close work ticket
5. Queue customer satisfaction survey requests

Next week, I am trying to complete "Identify Customer - Automated through asterisk", to which I am very close. I will be back into data conversion and correction mode early in the week and working with some domain experts here to get the next block of data bits in line.

Many of these stories play into each other. For example, two other stories (Poll Asterisk Queue, Present Asterisk polling results) were completed when I wrote the code this week for the Helpdesk Monitor (aka, Thompson Turkey). The queue monitor rose in priority this week as Queue Tip continues to fail on a daily basis, sometimes several times a day. This usually results in one or more emails, phone calls or visits to a technician, who must then reset the application.

Because I was preparing to work on the "Identify Customer" story, the Helpdesk Monitor was a great test-bed and served the purpose of retiring Queue Tip.

The YAGNI Principle

I have already received a number of requests for features in different parts of the app.

YAGNI stands for "You Aren't Gonna Need It". Developing under the YAGNI principle means that all feature requests and software development tasks are run through the filter of "Is this required? Is it desired? What will it cost? Can we make that money back? Will anyone actually use it? Has the person requesting the feature thought through these same questions? Do they fully understand the domain?".

Continuous input from folks in various departments helps to keep all stories in context of what is TheNextMostImportantThing and therefore helping move this project into the black as it saves the company money...in effect allowing it to pay for itself.

Out With the Old…

…and in with the new:

Screenie showing contact info, time in queue, 
customer feedback and technical rating of the caller. 

I am really trying to follow some of the current trends in visualization.  What I’ve come to learn is that software users know what they want to do, they just don’t know how they want to do it.  What’s worse is that we’ve reinforced behaviours developed under poor software design and now many of us in the software development world are guilty of holding up those behaviours to point of encouraging them.

When a call comes into our helpdesk, the service reps don’t want to see all of the customer information; they want to see the information they need to confirm a customer’s identity.

The previous version of the software, which officially began development nearly a decade ago, wasn’t focused on a role or a task.  It was data-centric.  If you requested to see more data – because it would better serve your role or task – it was layered onto or composed into existing screens. 

The end result was that, over time, data started get lost.  Many bits of data were forgotten about, overlooked, under-used and – worse – re-implemented in different areas with slightly different meanings.

Using MVVM and WPF we are already improving the experience for the customer by improving the experience for the call staff.

I’m not saying I knocked it out of the park here, and arguably, someone with a little more design experience could improve this dramatically (go ahead! Write your own View and bind to my ViewModel!) but I think this is proof that software can look sexy and be functional at the same time.