It's been awhile since I played around with Oracle, and for me, the introduction of schemas in SQL Server 2005 really went unnoticed.  Well, today it came up and bit me in the backside pretty savagely.  It's quite obvious, (like everything) but the following code created a few issues for me...

IF EXISTS (SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = "Address")
DROP TABLE Address

The issue? If any table in any schema has the name Address, then it will drop my table. The fix is pretty easy...

IF EXISTS (SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = "Address" AND TABLE_SCHEMA="DBO")
DROP TABLE dbo.Address

As I said - obvious.

Trying to take on legacy code can be quite difficult.  You need to understand the business logic.  You need to understand the underlying architecture.  You have to learn the new frameworks.  And you need to understand the why.  This difficulty is compounded when you not only have to wade through a morass of existing code that works, but the plethora of tables, stored procedures and business objects that have been retired but never actually removed from the codebase.  I'm not sure what the phenomen is, but some programmers are hoarders.  In another life, they'd be the person that has ten year old newspapers stacked up in a kitchen because they might need it one day.  Or they still have the key rack they made for Fathers Day in preschool with the garish purple paint and the bent nails because they can't bear to throw it out.

I think the other big trap that catches the developers out is the urban legend that rewriting the code is faster than refactoring.  So a whole bunch of new objects and new methods are made, new tables are introduced, and then finally, the new code is "pointed at".  The old code is no longer referenced or used, but it's never actually deleted.  Unfortunately, it stays there.  Eventually, the individual responsible leaves.  The old code still looks like it does the things that it's meant to do, but it doesn't actually do it anymore as it's been replaced and nothing points to it anymore.  Tools like resharper aren't able to recognise that they're not used because all the plumbing still exists!  These developers might not be code hoarders, but they nevertheless leave a trail of obsolete but apparently useful code in their wake.

Fixing the code hoarder is not so easy.  Educating in source control, wielding a stick perhaps.  Code metrics highlighting complexities?  Not sure.  When the culture is to comment out but leave in, that's a difficult thing to change.  When you use a source control system that's not really up to it, that's also very difficult to change.  Wielding the stick can be a little easier - a senior developer running through a code review.  Paired programming with a non code hoarder.  I'm not really sure, but it's something I'd love to figure out.

Fixing the rewriter?  Refactor.  Migrate the old code in small, bite size steps.  Refactor tables using database refactoring techniques.  You're actually changing the code instead.  The code evolves and morphs into the new code, and we're not left with a bunch of year old stale code that some other developer may have to wade through down the track, only to find out that it's a red herring.  Introducing effective refactoring tools can go a long way towards this.  Even simple things like allowing users to quickly change the names of variables and methods can quickly improve the quality of code - often to the point where the desire to rewrite is no longer an overriding desire.  As code evolves, obsolete code has a way of just disappearing, and the "rewritten" code just magically takes its place.  Introduction of database refactoring techniques and working with legacy code techniques.  Overall, in these cases it's more about education.  I often find that once I've shown somebody how to refactor towards the design goal, people take it on.  It's much easier both in the short term, and in the long term.

Attended a Thoughtworks presentation this morning - "Your first mistake - underestimating the customer experience".  Interesting way at looking at why customers choose between products and companies.  The gust of the presentation was that companies need to look beyond competing on price, quality and time to market, and look at differentiating your product based on not just whether the product does the job, but the entire customer experience - from hitting the website, to installing or using the product, to customer service when having issues.

The factor contributing to this change in focus is the impact that Web 2.0 has on assisting customers to choose brands and products.  With growing numbers of people writing reviews, blogs, participating in forums, and generally publishing information - word of mouth is now reaching many many more ears.  Whilst in the past you might get newspaper reviews, or a personal recommendation, now you can Google virtually any product and find out what other customer experiences have been had with that product.

A brief rehash follows...

Designing for everybody pleases nobody

It's important to consider who you are targeting as customers.  Ideally, the ones with the most money to spend, the ones that are easy to attract, and require the least amount of effort to maintain.

Once these customers are identified, research is required to really find out what motivates them.  From market research, with its corresponding downside (don't actually do what they say they do), through contextual research (finding out how they use your product, (or similar)), right through to "ethnographic" research (really getting out there and following your customers and finding out what motivates them to choose a product).

At this point it's important to build a customer profile.  This helps to identify the customer, and make them a real person.  'I want to be a real boy" -Pinnocio.  Make these customers obvious and display the profile.

Identify

• Demographic
• Interaction Experience
• Attitudes to task and technology
• Goals
• Experience Statements
• Environment (where is the product used)

Goals are the new features

I wasn't really sure how the tagline related to the content, but the content was definitely relevant.  Essentially, like any good analyst, focus on identifying the customers "want", "need", and "feel" words to help identify there goals.  Also try and identify their frustrations.

Possibly relate to Maslows needs hierarchy - when all the basic requirements are met... then what does the customer look for?

Some ideas

• Motivation
• Practical Need
• Brand / image
• Environment
• Emotional Need
• Interaction
• Social Need

They also touched on capturing user goals using stories - something along the lines of
As a <Customer type>
I want to <action>
so I can <goal>

Finally, it was a matter of prioritising the user goals - high value, low cost -> high value, high cost, -> low value, low cost -> low value, high cost.  (Guess which ones don't get done!)

Useability is not rocket science

I kind of found that a bit condescending, but again, the content was excellent.  It focussed around "eating your own dogfood".  ie - act as a user and use your site, product, service to see how user centric or goal focussed it is.

They did an 8 second blip of the Surf Lifesaving South Australia website.  I am a beach goer and I want to view the site so that I can donate some money.  8 seconds display... can you find it?  (Donate was very well hidden away).  To be fair to Surf Lifesaving SA, maybe their target user wasn't somebody donating but somebody wanting to become a member.  (See point 1 - design for everybody pleases nobody)

Also, I liked the point about using natural language - illustrated quite amusingly by using a Virgin Blue hostess comment about the emergency exit door...  "If I say get out... open the door quickly."  That struck a cord with me as I'm a big fan of avoiding buzzwords and wank words when not needed.  (My pet peeve is "If you need assistance please do not hesitate to ask".  Which is wank phrase for - "Ask if you need help").  Politeness CAN obscure the message.

Another point made that I appreciated is that the product should be consistent across all mediums.  If you login to a site and start an application, you should be able to complete that same application over the phone (if a phone service is provided).

Leverage Web 2.0

Maybe my attention span is short, but I found that the presentation started to wander at this point.  The crux of it was to pay attention to Web 2.0 features like forums, mashups, blogs and review sites where users contribute, and use those to help with points 1, 2 and 3. 

• Noted that consumer publications and media was no longer as trusted
• Peer reviews were preferred forms of information
• Noted businesses starting to have Facebook pages to provide a peer style site and promote the brand
• Use the internet to identify competitors and find information about it.

Change

"The only constant is change".  This last section wandered the most, and it became a little trite.  Essentially it was about making change part of the process, and making it evolutionary rather than big bang.  It's more approachable that way.

All up though, I found the presentation quite informative and some of the techniques very useful.  I can't say that there were any bombshells and a lot of it's common sense, but sometimes it takes an external party to make you realise what you're missing - and for that, it was definitely a good thing.

Two months ago, after repeated issues with billing with People Telecom, I decided that it was time to change provider.  I rang GreenTreeFrog, and actually got somebody on the phone.  Purely because of that, I signed up for 12 months.  After some stuffing around with PeopleTelecom who were not very forward in providing me the information required, I was able to get connected.  Finally, the accounts were cancelled, and at last - I'm done with bad service.

Alas - I received an invoice in October.  Contacting them was rather difficult.  Waiting on hold for 20+ minutes, eventually, I tried email..  nobody responded.  Today, I received another invoice.  This is despite repeated emails to their support system.  Finally, I've had enough - I'm going through the Telecommunications Industry Ombudsman.  It annoys me that I have to do this, and what's worse - this is the third time that I've had to do it in order to resolve the situation.

Why am writing this?  To let anybody who reads it know.  Avoid them.  Do yourself a favour.  It's a real shame because when they were SwiftTel, they were great.