A LESSON FOR US FROM A REAL ESTATE AGENT

So am I writing today to pick on poor real estate agents and radio ad copy writers that accidentally pluralize ‘Internet’?  Nope, I am writing today because each time I hear the  advertisement it reminds me that not everybody on the planet is ‘in’ the information technology business.  This is important to remember for everyone involved in making or changing applications in any way:  project managers, software architects, developers, quality assurance staff, documentation writers, and technical support staff.

You can design and build the most fantastic application in terms of functionality and rock solid quality.  Without being usable by the intended audience, however, such an application is just as doomed to fail as one that is sparse in features and bug-ridden.

ENSURING USABILITY

How can you ensure usability?  First, it is important to understand that usability does have some core characteristics that apply across the vast majority of user audiences.  These are such things as following Windows conventions for the placement of menus, buttons, button names, button actions, etc.  In this regard, it is very important to NOT reinvent the wheel, i.e. stick with what is out there in common use.  Folks will thus have a head start on understanding how to run your application.

Second, usability beyond those core elements does change from user type to user type.  An application to help developers find memory leaks should thus have a user interface that differs materially from a bank teller application.

WHAT IS THE USER LOOKING FOR

So the core conventions are easy to determine and follow.  It is the special nuances that your particular set of users are expecting that are the difficult part to discover and implement.  You will need to determine who your users are going to be, what area of expertise they have, the terminology that is common among them all, and the lowest common denominator of information technology competence.

Each industry has its own ‘language’–terms not used anywhere else, or meanings for words that differ from how we use the same words outside the industry.  If your application is to appeal to these users and also to ease their learning of your application, you must be aware of these terminology needs and make use of them–or at least avoid any ‘faux pas’ by using words in wrong ways.

LOWEST COMMON DENOMINATOR

When you are looking to determine the lowest common denominator of information technology competence, you are not looking for the single most technologically challenged user in the group and then building the user interface to accommodate for them.  Your application would drive everyone else crazy in trying to be too simple to run!  Remove the outliers from consideration and look to where you find a strong cluster of users at the lowest level of information technology competence.  That’s your target of where to make your application usable with user interface design.

MULTIPLE WAYS TO RUN

Finally, if your user clusters are varied in industry and IT competence, you can always bundle different user interface packages to suit each cluster.  Investing the time to make your application as usable as possible to each different audience you wish to sell to will pay off well in increased sales, happier users, and reduced technical support needs.

Hey, do you think ‘See you on the Internets!’ has any change of dislodging ‘All your base are belong to us.’ from fame and fortune?

See you on the Internets,
Dean Whitford, B.Comm.
Chief Operating Officer
DraftLogic
www.draftlogic.com

SAY IT AIN’T SO, DEAN!

How did an ‘old development management sea dog’ like me get stung by not complying with these rules?  Well, truth be told, the reason lies with succumbing to two of the seven deadly sins!

Isn’t it funny how most of our human errors can be traced back to that simple list?

FEATURE GREED

My first sin this week was GREED–specifically, feature greed.  Talking only about development related sins, of course!  I wanted to show the potential client ‘the lastest and greatest’, ‘the best that we could be’, ‘the goodies’, you name it!  My rationale was that there had not been many changes to the application executables in the prior week, so after carefully testing the changed functions and passing them I thought I was good to go with the new stuff.

In the haze of feature greed, I forgot about our old friends ripple effect and fault feedback ratio.

TINY LITTLE WAVES MAKING BIG PROBLEMS

Ripple effect, for those not in the business, is when you change something ‘over here’ in your code and it breaks something ‘over there’ in your code.  It can be the fault of the developer not following through with a change to all affected areas or it can be the fault of the project manager not seeing all the modules that will be affected by a change and assigning all developers that own potentially affected code to do the necessary work to deal with the effects of the change.

In this particular case, I took a delivery from one developer that resolved some errors in one module, all of which tested good, then I took another delivery of fixes from another developer in a different module, all of which tested good.  It was the combining of the deliveries that was the problem–fixed functionality in the one module made code in the other module (changed weeks ago and tested OK at that time), blow up on finding data again where it was expected but in a now unexpected format.

NOBODY IS PERFECT

The essence of humanity, none of us is perfect, is demonstrated through the fault feedback ratio.  Nobody can go in and fix an issue without ever breaking anything else.  Developers that are very careful will have an extremely low fault feedback ratio, but even the best will break something else when they go in to make the fix.

This was the root of the issue that caused the error during the demo.  Code that at one time was synchronized with the output of the other module became unprepared for all possible variants of that output when a change was made in module A by developer Z.  This remained undiscovered for weeks because prior to Z making the change in A, developer X had broken module B so that it had no output whatsoever.  So only after the now broken module A was put together with the now fixed module B did the new error show up.

SUCK IT UP, PRINCESS

The net cost of my sins is the endangering of a sale that should have been a lot easier of a closing.

If you are not completely willing to bear the worst case possible outcome of a blown demonstration or production roll out, don’t release to production before something is completely ready and tested!  Given the vast cost of ‘broken arrow’ releases when you multiply by the number of users that you will take down for a while, premature production releases are simply not worth it.

FIGHT THE POWERS THAT BE

In my case, the decision was mine–no one was pressuring me for a premature release.

In many other cases, possibly yours, there is plenty of external pressure for you to release before you know you are really ready to.  You must resist, do not join the dark side!  For those that persist, quantify the worst case scenario in terms of user downtime and lost sales (or whatever set of effects would result) and the overeager stakeholder should relent from pressuring you…at least a little bit.

AN UGLY WORD UNLESS YOU ARE TALKING ABOUT THE SLOW TREE DWELLER

The second sin of the week was SLOTH.  In today’s parlance ‘laziness’.  I like to make it sound less bound-for-hellish by saying ‘lack of time’.  A proper amount of time allocated to make the proper tests would have exposed the issue and ensured that I stayed on the last release for the demonstration instead of the new stuff.

If one cannot make the time to get the proper tests done, one should not use the new release.  My failing was having a busy week with other matters and simply not having the time available, but in still doing the point tests and thinking that was enough.  It wasn’t, of course.  Complete system tests need to be done prior to releasing any code from development to production environments.

Licking my wounds,

Dean Whitford, B.Comm.

Chief Operating Officer

DraftLogic

“That doesn’t make any sense” you say?  Or perhaps you think the last percent of work should not be any different from any other part of the work?

Following that logic, our 20,000ish hour development effort should take a couple hundred hours for the last one percent to be finished.  The reality is we have burned five hundred or so hours and counting.  The light at the end of the tunnel is in sight but we are crawling toward it instead of running!

There are a number of reasons for that last percent of work taking such a disproportionate amount of effort to finish off.

HUMAN NATURE

A big part of it is the developer’s succumbing to human nature and the project manager letting such a thing happen…because it seems harmless when you consider the decisions one by one.  What I am referring to is most people’s tendency to go for the ‘easy kills’ when assigned a number of tasks.  We do that because we like the feeling of success and forward progress we get when we finish a task.  In organizations where there is performance evaluation based on completing tasks and having quality assurance sign off on them, going for the easy kills is sometimes an act of survival, i.e. the system makes you do it, regardless of whether you want to or not.

The project manager’s part of this is either not assigning a priority to the tasks to ensure that things get done in a particular order regardless of their relative difficulty OR in letting it slide when some of the developers skip the hard stuff.  My sin is usually the second type.

BACKWARDS RIPPLE

Another material contributor to the hours spent finishing the last percent of work is dealing with more ripple effects than usual.  Once your application is basically completely built, any change you make has a higher probability of affecting more code–much more in both respects than when you are first starting to build the application.

LATE STAGE REQUIREMENTS CHANGES

In the same light, requirements changes that are introduced at the end of the job have a higher probability of affecting more code.

DEALING WITH IT

So now we know how we got to this painful stage, how do we get through it?

This first thing is to manage the expectations of all the stakeholders.  Let them know that the task list is much shortened from before but that the items left are difficult and risky.  Let any of those who are asking for requirements changes know the full potential impact of their requested change & suggest, where feasible, that the change would be best left until after the first version of the product is tested and released.

The second thing is to maintain the development team’s morale.  Grinding through the tough tasks and dealing with ripple effects is going to be stressful, especially for those who either need or are used to frequent gratification from completing easier tasks.  Congratulate each developer for the small gains that will be made as they happen.  Keep the team updated about progress that is being made.

Finally, stay positive and stay focused!  Your clients on the one side and development team on the other will sense any fear or negativity you feel–and it will adversely affect their attitude.  Celebrate progress made, however glacial.  You need to keep your focus, the clients’ focus, and the development team’s focus all squarely on completing the product.  You will need to be strong in resisting any changes that are not absolutely necessary, whether proposed by the client or by your development team.  In this light, you need to be prepared to re-evaluate the inclusion of any functions that are causing major problems.  If feasible, delay a troublesome function for later in order to expedite the completion of the release.

NEXT PROJECT

OK, so you and your team pushed through the resistance and finished the release.  Can you avoid making the ‘last percent’ so painful on the next project?  Well, you won’t be able to get rid of all the nasty nuances tied to the last percent of work, but much of it can be managed away.

Ensure that your developer performance evaluation and task tracking system are sensitive to task difficulty and priority.  Do this by assigning higher completion credit to difficult issues & assigning an exact relative priority to each task.  The completion priorities must be enforced throughout the project, otherwise the tough items will pile up for late in the project.

Throughout the project, carefully evaluate any change requests, whether from clients or the development team, for the degree of ripple effect and for how truly immediate they need to be.  Change requests that can reasonably delayed to a future release should all be delayed.  Ones that cannot be delayed will need to have their time required, including dealing with ripple effect and added quality assurance time, push the project completion date forward commensurately.

Until next time for more software engineering ramblings,
Dean Whitford, B.Comm

Chief Operating Officer

DraftLogic