Whenever I talk to a customer about something which is clearly in my domain (anything related to web application development), I try to ensure that everything I want to say first goes through a ‘customer translator’ which turns my domain knowledge into something they might understand. This translator works in the opposite direction too.

However, I’ve realised this week that this approach is sometimes required for people who work in the same domain or have similar roles to me. The benefit of using domain knowledge and terminology is that it allows you to be explicit and succinct. However, if others aren’t being as explicit or succinct as you think they should be (inferring their expected expertise) then problems can occur. My advice is to question everything, especially if it just seems wrong. Sometimes just one character can make all the difference.

Our business sometimes gets asked to advise on either computer software or web applications that could help a business improve its efficiency or communications. Invariably, the opinion of clients is that problems will be solved, in one way or another, by software.

The truth is different: an inefficiently run business will only become better at being inefficient, by using software or a web application. In most cases adopting this technology will always make a business less efficient, at best, in the short term, at worst, forever. Instead attention should be given to what a business has or doesn’t have. In particular, there are three things that a business should have before it even starts to consider technology:

• The right Policies
• The right Procedures
• The right People

Technology is only there to empower and enable people to carry out procedures more effectively. There is no simple solution or quick fix.

I refer to the Help menu option that lives at the top of almost every application. In my experience people never use Help, nor do they use the internet to find the solution to their problem. This means we get a lot of phone calls and e-mails from customers. We act as a verbal reference manual. The consequence of this is that customers don’t learn either. Much of their day to day work is simply replicating what they’ve done previously, without attaining any knowledge of why they are performing specific actions, or how specific actions complement the rest of the things they do.

But software manufacturers don’t make it easy for people to get to achieve their goals. Take this example from Windows Vista: suppose you want to change the resolution of your display. This is what you have to do:

1. Click the Start button
2. Click Control Panel
3. Click Appearance and Personalization
4. Click Personalization
5. Click Display Settings
6. Find the section labelled Resolution
7. Move the slider to the resolution you want
8. Click Apply

This is what you have to do on a Mac:

1. Click the Apple logo in the menu bar
2. Click System Preferences
3. Click Displays
4. Click on the resolution you want
5. Close the window

Note: moving a slider to change resolution is just plain wrong. On earlier versions of Windows – and it might be the case with Vista too – you don’t know what resolutions you can choose from until you start moving the slider. Furthermore, resolution is not a linear relationship.

All of this reminds me of the days prior to Mac OS X. It’s predecessor operating system for Macs came with on-screen guides that steered the user interactively through common operations. Not by just showing a series of screenshots, but by actually doing the work for the user, highlighting the various steps to take. This was far superior to anything around today.

An interesting post over at 37signals suggests that it’s good to give up on a feature that’s taking too long to implement. This is a great tip if the pain of implementing a feature outweighs its value or benefit.

A better tip is to properly assess the value of a feature before starting to implement it. When you’re familiar with the environment in which a feature is to be installed, and you’re knowledgeable about the users and use of an application, you can assess such things as:

• are there other ways of achieving the same outcome using existing features?
• how often is this new feature going to be used?
• how critical to the application (or business) mission is this feature?

I have another tip: don’t even start thinking about implementing something until your customer has asked you for it a second time. (Children reading this blog should ignore this particular tip!)

I must however suggest caution with this approach: because to be able to persuade customers not to add a feature, for whatever reason, requires trust between customer and supplier. For large projects, we build trust by finding out about our customer and how their business works. The primary objective of this activity is to gain enough knowledge and information so as to be able to implement what they need effectively – which isn’t necessarily what they ask for! Indeed, we often advise on making changes to their business process, reducing the amount of work we have to do! Sometimes people get so caught up in the mindset of a ‘contract’ that they forget what they’re in a contract for.

The reason why engineers don’t want to give up is because of the perceived loss of engineering effort: their part of the pie, their code legacy. Gone forever. I’ve worked with software engineers who have been distraught at learning that their software is to be discarded – either unwanted or superseded. But they really shouldn’t have worried: it’s all history – get over it and move on.

You can apply these tips to real life too!

As a software engineer, one usually spends a lot of time and intellectual effort on learning new stuff – languages, components, tools. With the rise of Rich Internet Applications there are lots of different ways of doing similar things. I’ve tended to keep hold of the tools and methods that I’m most familiar with. Notably, the suite of Prototype, Script.aculo.us and Behaviour libraries.

Over the past couple of months, I’ve become increasingly aware of Yahoo’s YUI Library. A substantial and growing collection of interface elements and manipulators that are, in some respects, astonishing. But the learning curve is great. Would I – could I – switch to this instead?

Probably not for existing projects. But for new ones it seems viable. Yesterday’s release of version 2.2 includes such goodies as a browser history manager and a component for building and manipulating data tables (including XHR support!)

But that’s not all.. because David Lindquist has just released a one-column version of a navigator that behaves similarly to Apple’s Column View, and there’s a multi-column version on the way. Gosh.

If you have a responsibility to manage things, you’ll often feel pressured to make quick decisions. Early in my career this was certainly the case. I’d be in a meeting and some quite sensible, appropriate, question would be asked and I would have to give an answer. I’d either make what would turn out to be the wrong decision, or worse than that, I’d end up admitting that I didn’t know what to do.

Which brings me to “Hmm.. interesting”, which Kathy Sierra recommends saying (or thinking) “before you say or do anything else”. This advice to think about something, even for mere moments, before acting is fundamental to good management. The public counterpart to this is to defer a decision, but in a way that conveys action and responsibility. The usual way to do this is to say “let me get back to you on this issue”. But that’s no good. What people should want to hear is “let me get back to you on this issue before [insert date or time here]”. This publicly prioritises and commits to a resolution. If you do this when required and more importantly deliver on these commitments you’ll be a better manager.

One of the things I do a lot more of now, working in my own business, is thinking. I spend an awful lot of time thinking. Sometimes without writing anything down. I think about the work we’re doing a lot of the time outside of working hours, although it doesn’t feel like work. In some respects, the “let me get back to you” response has evolved into a “I need to think about this”, although I’d doubt you could use this reply in the corporate world – it seems a bit, um, woolly. But I am now renown to some customers as a thinker.

For example, I’ve recently been thinking about implementing solutions to a number of new requirements for a web application. Here’s a summary of what those requirements are:

1. Integrating a manufacturing process with a sales process;
2. Allowing stock to be sent to external suppliers for further processing, then received back into stock as different items;
3. Reporting on the building of stock from component stock parts.

Three distinct problems on which I’ve been thinking for the past three to four weeks. Yesterday at around 11pm I came to the conclusion that they were all similar requirements that could be solved in a unified way. I’ve saved a lot of development time because I sat on these problems, rather than just picking one up and implementing it. Some might say that this is just the result of good analysis, but the lesson to learn is that there often are good (and easy) solutions to problems, no matter how obtuse or difficult those problems might appear.

Which leads to another conclusion: 37signals’ post titled “Degrees of Can’t” indicates that it’s easy to close the door on something by declaring it impossible to do. I’ve known many junior managers who have used this tactic. In practice it is rare that something cannot be done. Usually it just requires some thought and analysis. A moment of “Hmm..”