When do YOU look at the user?

Think about it. You're putting in this cool new feature, it's going to save the users a lot of time, give them a ton of functionality and, hence, save them a truckload of money. AWESOME!

So, first we nail down the functionality... right? WRONG!!! First you figure out how the users will exercise the new functionality, because that's what you're ultimately giving them- a new user experience. a new interaction mode.

Unless you make sure the user is going to find the new interaction intuitive, any new functionality, however efficient, is a burden. If you make the user jump through a lot of hoops just to do his everyday job, your new feature SUCKS!!!

I actually experienced this first hand recently. We enhanced the TIL Regulation dashboard in an LOS to allow the users to monitor loans as they get dangerously close to the limits and notify them once they fall over. I actually reordered all the controls on the screen just to keep logically related data together. The new design was so intuitive that the Business Analyst approved it in a heartbeat and sent out an appreciation note! (Pat myself on the back)

At the same time, another team member was working on the screen used to configure the regulation limits. Man did they miss the bus! They wrote up the whole screen, new popups et al, and then sat around thinking, 'What if the user checks this but doesn't fill in that...?' WHOA! When he asked me for an opinion, I said that the new validations he was thinking of were cool, but, '...wouldn't it have been much more logical to have thought about this BEFORE you built the whole thing?' Nevertheless, he ended up putting in the validations (in this screen and a few others!). Rework can be such a productivity killer!

The user always comes first. Kathy Sierra agrees in her blog post captioned Ignore the competition.

Lessons Learnt

I haven't exactly been soul searching, but here's my list...

This entry is waaaay overdue! 5 months SUCKS!!! I definitely need to post more often.

Fight the PROBLEM, not the PROJECT

Never compromise

Always understand what you're getting into

Don't hold on too hard

Assumption is the Mother of all F**k-ups

I am a Maven looking for a Connector

Don't bite more than you can chew

Coding vs Programming

Coding is about how you should write,
Programming is about how you SHOULDN'T!

Coding as about the Language and Syntax,
Programming is about the Paradigm, the Thought Process

Coding is represented by the 'Writing' Metaphor,
Programming is epitomized by the 'Construction' metaphor

Coding defines the Solution,
Programming defines the Problem too!

Coding creates the Implementation,
Programming creates the Interface

Coding is about "Getting it done...",
Programming is about "Getting to know it!"

Coding gets you Paid,
Programming makes you Satisfied.

Coding is what we HAVE to do,
Programming is what we SHOULD be doing!

Continuous Care Vs Initial Design

In his paper titled Continuous Care Vs. Initial Design, Robert Martin expresses his growing concern regarding the lack of awareness about creating maintainable systems. Quite like I mentioned in my first blog entry 'How do you measure Quality?', he points out that we must strive to finish a task right (for everyone) as opposed to just finishing it. The article goes on to describe why systems, no matter how well designed, can be reduced to a rotting carcass simply due to negligence. Every time a design is changed as a result of requirements changing in ways that the initial design did not anticipate, new and unplanned dependencies can be introduced between the modules if the changes are made without carefully considering the system's existing state. The latter half of the paper suggests the application of Agile Methodologies to counter such 'rotting'.

Hmm... we all seem to agree to that. So, what could we be looking at wrong this time? :)
Good old CONTEXT! ;)

You see, Martin talks of designing in the small (Agile). It's about how initial designs can never keep up with changing requirements. What I'm hinting at is that all the talk of Continuous Care is applicable to new development. Projects being planned now, to be developed tomorrow!

The whole thrust of the paper is towards changing engineering attitudes, about changing Methodologies. You can't change your methodology once the plane's taken off! Besides, no volume of care could ever fix a screwed up initial design. Martin says that , according to the Agile methodology, designs must be built to change and new requirements can change the design fundamentally too. But, how much 'care' do you put in before it's officially called a redesign!

With regards to Agile development, well I'm not a really big fan of it but I don't particularly think it's evil. The thing about the Agile methodology is that it's just plain simple misunderstood. Most uninformed people think being Agile is about getting it done in the simplest possible way in the shortest possible time. Well, I suggest they either read up on Agile development or com up with their own independent manifesto!

Personally, I'm a big upfront design guy. I find safety in sitting calmly and applying 'care'ful foresight to come up with a flexible, extensible design (I know, I know... how does the customer care! Customer's suck!!). That's why I think being open minded is more important than being Agile.

Sidenote: Here's a few more options, take your pick...