Archive for the ‘Software Engineering Musings’ Category

DraftLogic Electrical and Untrained Users…A Cautionary Tale

Monday, May 13th, 2013

This cautionary tale applies to all software that provides any degree of automation, herein we will focus in on the DraftLogic Electrical building electrical design expert system.

The Power of Automation…and Power Tools

Comparing the productivity of DraftLogic Electrical versus raw AutoCAD, Revit, or the MEP versions thereof is like comparing a jackhammer to a 10 pound sledgehammer…the productivity difference on a job of any material size is immense!

The Danger of Automation…and Power Tools

Similar to the jackhammer versus sledgehammer comparison, however, the user of the tool must know how to properly use the tool. An untrained jackhammer user is likely to hurt themselves rather than do a quality job in an efficient manner without injury. DraftLogic Electrical adds lots of building electrical design functionality to AutoCAD. Much of this functionality is highly automated expert systems tools.  Typically, the more a particular tool does for you, the more important it is to provide good base data to that tool.

A designer untrained in the use of DraftLogic Electrical is highly likely to feed bad data into the expert system automation and thus make things harder for themselves. How can a designer create bad data? Well, AutoCAD is basically a completely open design environment…you can design what you want how you want. This is great for design flexibility, not so great when you are trying to help a user create a CEC or NEC compliant building electrical design and using expert systems automation to help the user get to a completed design a lot faster.

What are some of the things that untrained users can do that will make trouble for themselves?  A good example is failing to use the Circuit Manager to create relationships between distribution devices. Users manually filling in the parent ID and circuit attributes on distribution devices will often mistype in one or the other, or leave one of them completely blank. They will also use the same circuit number for multiple devices. Phase, pole, and voltage incompatibilities are often created. None of these things can happen when the Circuit Manager is used–that’s why the training videos tell users to use the Circuit Manager many times.

The Cautionary Tale

I recently assisted a client with a fair-sized project, likely 400 person hours of design work if done in raw AutoCAD or AutoCAD MEP…more if done in Revit or Revit MEP. The project was started by one user on DraftLogic Electrical but due to resource constraints in the design firm was handed to another user early on. Unfortunately, only the initial user had taken the time to carefully go through the training program.

The second user ended up manually populating their circuiting relationships, with errors in almost every one, rather than using the Circuit Manager & also manually populated feeders rather than let DraftLogic Electrical supply code-compliant feeders for everything and only after that override those select few feeders that are desired different from a basic code compliant calculation. These errors jammed up the reporting automation completely.

Much badness resulted: I had to perform a detailed review on the drawing, the user was frustrated because their project was halted, and after my review they had to rework basically all of their distribution circuiting. We got everything sorted out and put the project back on track, but at a cost–the project should have taken 120 hours or less in DraftLogic Electrical rather than 400 in AutoCAD but due to the errors I am pretty sure the hours ran up to over 250.

Let Their Painful Lesson Save You the Same

In summation, AutoCAD is the wild, wild west for the variety of data that a user can create. In DraftLogic Electrical we attempt to balance between placing restrictions to ensure that users create good data versus not restricting their design efforts. It’s a tough balancing act, and throwing an untrained user into the mix is highly likely to make problems for all concerned. So please ensure that anyone you desire to enjoy the DraftLogic Productivity boost is given ample time to learn how to use DraftLogic Electrical properly. Their ongoing productivity gains from efficiently using everything that DraftLogic Electrical has to offer will make the upfront few days training time investment completely insignificant.


Dean Whitford
Chief Executive Officer
Phone 780-906-2888 (9AM to 6PM MTN time)
Visit us on the Internet:


Keys to Success for Learning to Use Software Built for Complex Tasks

Friday, February 10th, 2012

Learning New Software Blues

You know what?  I hate reading software manuals, attending software training courses, and watching training videos as much…or even more…than you do!  I can usually get away without doing any of that…with typical ‘consumer grade’ applications.  It is an indisputable truism, however, that not all software can be made simple and intuitive enough so that a reasonably intelligent person can sit down and effectively use it without having to do any of these horrible horrible things  🙂

In Our Experience

We at DraftLogic Inc. have been working with new clients and with potential clients that are setting up pilot projects and trials of DraftLogic Electrical.  Since what happens in the initial learning phase of the software determines whether implementation moves forward or not, we have learned some key factors that determine success or failure across all sites.

These key factors apply to all software that has a tough job to do. What do I mean by that?  Well, typically speaking, the more complex and knowledge intensive the end product, the more complex the software to help users create a quality end product. For example, consider AutoCAD, Revit, and enterprise resource planning products.  Each of these products requires a minimum base level of product knowledge before a user can be truly productive with them.  Sure, someone with reasonable computer experience can sit down and draw some simple entities in AutoCAD, but you and I both know there is no way that someone without experience or training will be able to create professional quality output without some training!

So let’s dig into these keys to success that you can apply to almost any software built for complex tasks, using DraftLogic Electrical as our ‘case study’.

DraftLogic Electrical is going to make your design time both more enjoyable and more productive. It does this by automating boring, low skill, and error prone tasks; thus freeing up much more of your time to be able to concentrate on the important design decisions. You will finish your projects faster and even be able to deliver more value to the client in the shorter design time.

The Three Keys to Success

There are three key things that are all necessary to be successful with DraftLogic Electrical. If you can make these commitments, it is highly likely that you will be very successful with DraftLogic Electrical, i.e. your design productivity will, at a minimum, double and you will enjoy your design time more. The more of these commitments that are not met or are only partially met, the more likely it is that you will not be successful with DraftLogic Electrical and you will miss out on a great opportunity.

Firstly, your company must allocate you paid time during regular workdays to do the video training. The hours required in total are 20-24 if our tutorial school is used as the sample, up to approximately 30 hours if you select one of your projects to try things on.  The video training must be completed in a span of no more than two weeks–any longer and you’ll forget the basics before you learn the other features! In our experience, it is also not going to work if the company asks a designer to learn DraftLogic Electrical ‘as they go’, ‘during lunch times’, or ‘at home in the evening/weekends’.

Secondly, you must go carefully through the entire training video series, pausing the videos often and trying each function on the tutorial school data.

Thirdly, you must not ‘spin your wheels’. We want you to have a positive learning and use experience, not get frustrated trying to figure something tricky out. Call for support when: there is a concept in the training videos that does not seem to make sense, a function does not work when you try them it the tutorial data, or there simply seems to be some instruction or information missing.  Spend a few minutes reviewing the video, quickly check for information in the forums, and perhaps read the particular section for the function in question in the user manual…but other than that, pick up the phone and call 780-906-2888 for help.  Spending a few minutes on the phone with us will save you many more minutes of frustration.  We have noticed that some folks tend to email rather than call, please be aware that email might not get looked at for some number of minutes so it is always best to call if you have a question that needs to be answered in order for you to be able to continue.

In Closing

I have two last suggestions.  The first is for those trying to help clients learn their software–you need both the executives and the users to buy-in to the above to make the learning process work.  The second is for those who have to learn any software built for a complex task–think of the end state of improved productivity with less effort that you will be in after training…that should help you to stay focused and gain maximum benefit from the training.

Happy Software Engineering,

Dean Whitford, CEO

DraftLogic Inc.


PS:  interested in seeing a sample video training program?  Check ours out.

National Electrical Contractors Association (NECA) Show Boston 2010

Friday, December 17th, 2010

DraftLogic had a booth at the recent NECA show in Boston.  It was our first public event as a company and the public unveiling of DraftLogic Electrical’s production release.  We have had users for years prior, but they were all beta sites helping us with development.  Gerry and I manned the booth & Ivy was our support crew.

The new convention center in Boston is cavernous, to say the least.  When we dropped by the day before show opening to get set up, we got a golf cart ride from the entrance to the NECA show hall which was at the other end of the convention center.  The ride took some time even though the golf cart was moving along at a good pace!  I think an aircraft carrier would comfortably fit in the convention halls…

Since it was a show for electrical contractors, the products and services being exhibited were diverse.  There were a number of estimating software companies, many tool vendors, surge suppression manufacturers, lighting companies, vehicles, and more.  DraftLogic was the only electrical design software being exhibited at the show.

Attendance was not dismal, nor was it what I would call busy.  In the prior trade shows I have attended as an exhibitor, there was always someone wanting to learn about your offerings.  When you are that busy, the day goes fast and you wish you had more time available to talk to folks.  NECA 2010 had a few busy times, but the sum total over three days was a few hours of ‘busy’.  The rest of the time we had to resort to mugging, which is what I call it when you have to approach walkers-by to let them know what you do and ask them if they want to know more.   Regardless of the method of introduction, we did meet some great folks & many of them would benefit greatly from using DraftLogic Electrical.

For all you software entrepreneurs out there, my recommendation on exhibiting at trade shows is to do so…but with extreme caution about which shows you go to.  An excellent show can make your year.  To qualify as thus, the show has to bring large numbers of folks that fit your target market to the show and structure the trade show and other functions such that folks have time to and desire to walk the show floor and see your offering.  The worst of the shows will do nothing but vacuum money out of your pocket and waste your time.  You will go in ready for lots of great conversations and you will come out feeling dejected and ripped off!  So carefully qualify shows by looking at costs and time versus who is going to be coming to the show, the quantity of prospects you think will fit your offering, and whether the show organizer is doing all they can to get traffic past your booth.

Lastly, do not be afraid to greet walkers-by with a two second catch phrase and question.  It is costing you a lot to be at the show, you need to make the best of it.  Make sure your question cannot be answered with a ‘no’ and that it qualifies the prospect as possibly a fit for your product or not.   Something like ‘How many design-build projects did your company complete in the last 12 months?’  This gave Gerry and I all the information we needed to know if DraftLogic Electrical was going to be good for the prospect or not & also raised the interest of those that were doing design-build work.

Will we attend NECA 2011?  Hard to say, which tells you that it was not anywhere near as good a show as we hoped for us!

Merry Christmas to all!

Dean Whitford


PS for Technorati:  BD6F246X82GH

New Software Tools — Not Like Classic Cars!

Monday, December 6th, 2010

Do you know anyone that owns a classic car?  They probably don’t drive it much, usually only a few km a year to go exhibit at a local car show or maybe even just a few meters a year to load on and off a trailer to transport to car shows.  The classic car is thus not used day-to-day for regular transportation needs, it has only specialized use.

Why the classic car reference?  Well, some software tools that are intended to be used day-to-day end up being used only for specialized purposes.  We think this happens because people have spent years doing things they way they do and would like to stick to ‘old reliable’ processes except where it is blatantly obvious that the new tools is best suited for a particular job.  The possible return to the company of the affected software tools is drastically reduced by this behavior, since the benefits of the tools are only experienced on occasional jobs instead of all possible jobs the software tool can benefit the company by being used on.

Some folks see a demo of DraftLogic Electrical or are trained on it and then assume that DraftLogic Electrical is suitable only for specific purposes…kind of like that classic car.  Well, today I write to let you know that we designed DraftLogic Electrical to provide you advantages on almost every kind of project.

DraftLogic Electrical has six phases of amazing automation:  automated room creation, automated electrical device placement, automated circuiting, automated branch circuit wiring, automated floor plans/reports/schedules, and automated export of the entire project into ConEst IntelliBid.  What we occasionally fail to communicate is that each of these phases of automation is completely separate and that the data needed for any of the subsequent steps can be generated using other tools that we supply.  So, for example, a user can manually prep the architect drawing for use with DraftLogic Electrical, place the electrical systems devices using our tool palettes, and use the Circuit Manager to manually complete all the circuiting.  DraftLogic Electrical sees all this completely manually created data as the same as data created by all the automated phases.  Subsequent automation works just fine with the manually created data, allowing users to take advantage of the automated branch circuit wiring, automated floor plans/reports/schedules, and automated export of the entire project into ConEst IntelliBid–regardless of how the devices were placed in the drawing and circuited.

And by the way, our ‘manual’ tools are not very manual!  DraftLogic Electrical devices know whether they are wall, ceiling,  or floor mounted and automatically snap and rotate to reference locations like walls and tbar cells.  Tools like auto reload and high volume move and copy tools vastly reduce the number of mouse clicks and keystrokes necessary to get the electrical devices you need into the drawing.  DraftLogic Electrical does not do absolutely everything for you and there are some things that we have not attempted to automate, namely high voltage applications and large industrial design needs. The key thing to understand is that even with projects where you will need to use your current tools DraftLogic Electrical can still integrate nicely with that project and deal with all the areas we do well. Any electrical loads, lights, receptacles, motors, panels, special outlets and auxiliary systems we handle efficiently, accurately and effectively.

After training new users on how to take best advantage of our revolutionary building electrical systems design software, DraftLogic Electrical, we know that it is absolutely vital that they use it as much as possible in order for the the training to have been useful.  There is a direct and strong relationship between familiarity with a software tool and the benefit that one can gain from it.  So even in the very unlikely scenario where using DraftLogic Electrical has the same productivity as your current processes in doing a project, there is benefit in using it due to the experience that the designer gains, thus improving performance on subsequent projects.

Are there needs you have on a project and you are not sure how DraftLogic Electrical can meet them?  Call or email me and if I can’t show you how DraftLogic Electrical can meet that need now, our development team will quickly add the needed functionality!

Kindest Regards,

Dean Whitford
Chief Operating Officer
DraftLogic Electrical

Technology Adoption Recommendations

Tuesday, April 27th, 2010


We all know that change is hard. Sometimes people make it harder by resisting change rather than embracing it…even if the change is to their benefit! Try some of these tips for maximizing adoption and minimizing resistance when you roll out change in your organization:

  • Demonstrate the benefits of the new tool to all affected & back it up with explanation of benefits to other staff for groups like IT that may not see direct benefit. The benefit to the company may sway some staff, but many will need to see benefit for themselves or their coworkers to buy-in.  Staff may benefit from the adoption of the new tool, for example, by becoming more valuable to the company—higher productivity, increased deliverables, and fewer errors all tie directly to higher revenue per employee & better customer satisfaction.  Staff that become experts  in the use of the new tool will drastically outperform those who are not—increasing the expert’s relative value within the company and thus their job security. By freeing staff from repetitive, low knowledge required tasks, staff will be able to increase their knowledge and skills in electrical design’s finer and more complex areas of knowledge.
  • An internal ‘evangelist’ for the new tool, i.e. a positive and knowledgeable person, will go far in preventing other staff from becoming frustrated with new tools and giving up or turning negative. Some refer to such a person as a ‘change artist’. We recommend that your most positive minded, change embracing, and experienced designer be trained first in the use of the new tool.  If the person has the traits mentioned, they will highly likely naturally slip into the role of internal evangelist. If reasonably feasible, reward this person for being first, being positive, and for making the adoption of the new tool a success—the rewards need not be monetary.
  • If involved from the very beginning in purchase and implementation planning, staff will be more amenable to the necessary process and standards changes that will affect how they work. Let staff know of the new tools on a timely basis, i.e. prepare them well in advance of the changeover so they don’t feel surprised or that their opinion on the changeover process was ignored. To increase buy-in, involve staff in planning the adoption process and in identifying what processes and standards will need to change.
  • There will be staff that resist the adoption of the new tools, you likely have run into their resistance on any types of changes initiated over their time with the company. Have patience and help resistant staff see the value of the new tools to them personally. Their conversion will not happen quickly but over time they will accept the change and may even become some of the strongest proponents of the new tools.
  • People learn best in different ways. Some learn best in a classroom situation, some learn best given time to experiment and dig around on their own. Budget time for staff to both take the training course and to have extra time on their first projects to allow for experiential learning, that way both types of learners will be accommodated. Ensure that all staff have unfettered access to either or both of expert internal assistance (from the evangelist mentioned above) and external assistance (from the tool supplier).
  • Any change requires continuous reinforcement to keep the change process moving forward. Once you have told staff of why the change needs to be made and how it will benefit them and the company, tell them again…and again…and again…until adoption is complete, which will take months.

Change is never easy, but if you do everything you can to involve your people early and often, you will have an easier time rolling out the change.


Management makes a decision to use new tools either because external forces have forced the change on them or because the tool will benefit the company. People in general are resistant to change of any type, beneficial or not, so there is always convincing involved, sometimes coddling, and sometimes forcing!

The organizations that are able to most quickly adopt new tools and benefit from them are those that are able to create and maintain an environment that fosters quick and resistance free adoption. To do this, they will make it clear that staff success in the organization depends on their ability to adopt new tools as required. Organizations can also accelerate tool changeover by removing the old tools or only accepting delivery of product created with the new tools.

The executive(s) that make the purchase decision are the ‘sponsoring executives’. It is imperative that these executives stay attuned to the situation through the purchase phase, training phase, and adoption phase in order to lend support or gentle pressure as needed to keep the process of adoption flowing.


Failed adoptions of new tools typically happen because the executives that initiated or sponsored the purchase of the new tool think their job is done once the purchase is made. Natural resistance to change in the organization thus ‘kills’ the new tool in a slow and quite manner.

The reality of the situation is that the sponsoring executive needs to remain involved from the purchase decision all the way through to the completion of adoption by all affected staff. The time required of the sponsoring executive is not much, merely ongoing attention and encouragement toward the adoption of the new tools. In our experience, this particular requirement for facilitating adoption is the single most important task that needs to be done.

We hope that the information herein will help you and your organization in adopting beneficial new tools.   A successful adoption will pay off many times over in ongoing: productivity gains, accuracy gains, and increased employee satisfaction due to reduced repetitive work.


Dean Whitford

Chief Operating Officer


Sunk Cost–Nothing to do With Ships

Sunday, April 4th, 2010

So don’t fall off your chair or otherwise hurt yourself in shock about what I am about to say…but the accountants have it right about something! What? After Enron and the financial crisis and countless ‘solid’ companies making it through audits and then flushing down the toilet? How could I say the accountants have anything right? Well, first of all, I am referring to accountants in general, not the auditors who have been taking a beating over the last few years.

The accounting concept I am referring to is that of ‘Sunk Cost’. This is a way of looking at an expenditure that was made in the past that I think could help with a lot of present day decisions for many companies. You see, being human we tend to cloud what should be rational decisions with human emotion. Not a bad thing when a decision needs some emotion in it to make it smart, but a very bad thing when including the effects of emotion in a decision will result in a wrong choice.

Get to the point you say? OK, here it is: a sunk cost is money spent in the past. It’s gone, over, done, finito. The only value you should be concerned about is whatever real value remains today in whatever you spent the money on in the past. In many cases, the current value will have little to do with the money that was spent. All too often, we attach extra value due to emotional attachment. That incorrect adjusted current value prevents us from making smart decisions today.

At DraftLogic, we run into the effect of emotionally upcharged value quite often. We’ll show our revolutionary new product, DraftLogic Electrical, to prospects and they are invariably quite impressed. They talk things over at the office about upgrading to our software & all the baggage comes out of the storage rooms: ‘We spent years or tens of thousands or both on developing our CAD standards’, ‘We just spent hundreds of thousands on coding productivity tools’, or ‘We have hundreds of thousands invested in a software platform that would need to be replaced’.

The question that should really be asked is ‘Will this new investment pay for itself and start benefiting us materially within an acceptable timeline?’ If the answer is ‘yes’, the purchase should be made and the old investment salvaged/used if partial need continues, sold if it has no current value for the company but retains some value for others, or abandoned if having no current value for anyone. That, however, is assuming decision makers and users can remove emotion and politics from the decision making equation…and when is the last time you saw that actually happen? Back to our accounting analogy, even auditors whom are supposed to be the arbiters of dispassionate numbers end up accommodating for human emotion and politics in their work, thus some of the company failures that took us all by surprise instead of coming with much forewarning from auditors.

So to you I wish the gift of vision unencumbered by emotional baggage or politics! The best I have been able to attain so far is twenty-four hour clarity on decisions where I have an emotional investment–today I render my emotionally muddled opinion & sometimes I have to come back tomorrow and say ‘OK, you were right, that is a better way & we should go with it’.

Kindest regards,
Dean Whitford, COO

Too Much Choice aka Featurus Overwhelmitis

Wednesday, January 13th, 2010

After Christmas Blues

The wrapping is in the recycle bin and the tree is back in storage…if you use an environmentally fake tree instead of something that gets burned after you use it for a few weeks.

How much use did the kids make of all the toys they received?  A couple of things still amaze me, even after my son’s fifth Christmas:  firstly, the generosity of his grandparents and aunties; and secondly, how little play time some of the toys get.  One can speculate that the toy designers are at fault & this is likely one of the factors.  In my son’s case, I think much of what happens or does not happen with the various toys is due to ‘too much choice’.

Too Many Toys

The fact of the matter is that he is spoiled rotten.  Hard to avoid when you are the only grandkid for four grandparents & thus also the only nephew for two aunties!  The gifts end up being either being used a fair amount over a long term, being used when mommy or daddy participate/mildly coerce, or simply not getting used.  When something comes in a really big box, the playtime with the box usually rivals that earned by the toy it came in.

Enough about kids and gifts and Christmas, otherwise I’ll start in on rampant consumerism being the downfall of western civilization!

How Does this Apply to Software?

Why did I bring up ‘too much choice’?  Well, the features of your application can end up in the same three ‘buckets’ as the toys: used a fair amount over a long term, only being used when trainers or support staff walk a user through it, or simply not getting used.  The worst of the second two classes of functions will not only not be used, they will get in the way and detract from your users’ quality of experience.  This is to say nothing of the extra time wasted in documenting, training, and supporting those types of features.

Featurus Overwhelmitis Causes

How does one get so many features in an application to cause Featurus Overwhelmitis?  For an experienced development team the reason is usually due to the higher the quality the development team, the more seemingly great ideas will be generated.  As project manager, it is difficult to withstand the constant onslaught of ‘great ideas’.  This is especially true if they are coming from your subject matter experts and you as project manager lack the domain specific knowledge to be able to separate the necessary from the beneficial but not necessary.  For an inexperienced development team, there is simply the feeling that users will see great value in an application if it has bazillions of functions.

The DraftLogic Electrical Experience

In building DraftLogic Electrical, we have tried to minimize Featurus Overwhelmitis.  On the intake side, feature requests and suggestions are carefully analyzed to determine how truly necessary they are.  Usually we can prevent low value add features from making it into the development schedule.  Where possible, we have completely integrated features into the workflow so that the user is not aware of having done anything extra, they just get the results they need.  Our fault levels calculations are a good example of this–they run anytime that the panel schedules, single line diagram, or bill of materials is run & ensure that those reports always have the most current data used in their creation (all load, protection, and feeder routines run for these reports–the user only has to call for the report).

On the development side, control is a bit harder.  Good developers will always have ideas about to do something better, take something farther, or offer another flavor of a feature.  The worst offenders (albeit well meaning) will go ahead and make extra features without clearance from the project manager.  Ever received three functions when you asked for one, accompanied by the comment ‘It was only a little extra time to do this that and the other thing so here are some great extras!’

The Repercussions of Giving In

I have to admit to occasionally succumbing to such deliveries and implementing the extra functions into DraftLogic Electrical’s menus and tool palette.  One such example are the three circuiting quality assurance routines.  Looking at them now, I wish I had sent the extra functions back and asked for the originally scoped single qa function that did it all.  I wish this so much that now I am going to have to allocate time for someone to consolidate them into one so I can get rid of the others and thus increase our usability.

Beating Featurus Overwhelmitis

So, project managers, stay strong and resist Featurus Overwhelmitis.  You can keep your development team and subject matter experts happy by adding ALL feature requests to a database or list.  When it is time to scope a new build, go through the list–when presented with cold hard choices of where to expend limited resources for development action items, a good development team will pick only the real gems for action.

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

Chief Operating Officer


Tool Inertia

Wednesday, December 23rd, 2009

Once upon a time, long, long ago, there was a caveperson named Pog.  Pog had a stone attached to a stick with a length of tendon.  Pog was very proud of his invention that made getting firewood easier & getting food easier.  Sure, the type of stone he used tended to flake and break often, but he was able to find replacement stones of the same kind easily.  Other cavepeople even copied his tool and made their own.

One day, Pog saw another caveperson, Grog, with a tool that had a shiny black head instead of dull grey like his.  Grog had discovered a deposit of obsidian and improved on Pog’s invention!  Pog found himself gathering wood in the same area as Grog and was amazed to see how much faster Grog was able to cut pieces of wood using his sharper and more durable tool.  Grog was happy to show any other cavepeople where the obsidian was, and many went with him to get their own pieces of obsidian.

Pog, however, had been using his dull grey stone tool for a long time and was comfortable with it.  He knew it took much longer to do everything, but the fear of trying to learn and use an new tool kept him from changing to the better obsidian blade.  Besides, Pog had invented the dull grey stone cutting tool, how could he abandon it!  In time, the obsidian users outperformed the dull grey stone users by such a margin that all the dull grey stone users died out and ended up merely as fossils buried in the soil.

How sad…if only Pog had not been afraid to adopt the newer, better tool!


OK, you got me.  That was a rather long winded way of pointing out that we humans often stick with what we know and are comfortable with rather than trying new things–even if there is a strong probability that the new thing will make our work easier and/or better in some way.

We saw this happen twentyish years ago with the migration from manual drafting to CAD (computer aided design).  Thinking back in your career, you can probably remember situations where you saw people and/or organizations resist change that would have benefited them.


So should we go ahead and adopt every new tool that looks like it might benefit us in some way?  Of course not–you don’t want to be a member of the flavor of the month club, endlessly hopping from one half baked innovation to the next.


You still need to perform due diligence to ensure that a tool is truly going to benefit you.  Once you have performed due diligence, however, don’t let tool inertia bind you forever to the devil that you know!

Dean Whitford, B.Comm.
Chief Operating Officer

See You On The Internets!

Wednesday, December 2nd, 2009

Today’s headline is courtesy of a real estate agent’s advertisement on my favorite radio station, SONiC 102.9 FM Edmonton.  The agent diligently repeats their web site address a couple of times and invites us all to visit and see their listed properties.  Being ‘detail oriented’, it makes me a little crazy every time I hear the ad and have to listen to the cheery closing line ‘See you on the Internets!’.  There is, of course, only one Internet…not a whole bunch.  And, yes, I am well aware there is a less polite way of describing those who are detail oriented…but I am trying to keep this blog family friendly so won’t be using ‘that’ word.


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.


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.


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.


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.


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

Maintaining THE WALL Between Development and Production Environments

Thursday, November 26th, 2009

Yesterday I was reminded, again, of one of my very old and very important rules:  any company involved with development must maintain a wall between their development and production environments.  A related important rule is that only releases that have been subjected to sufficient testing should be used to update production environments.


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?


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.


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.


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.


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.


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.


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