"Marketing": You keep using that word. I do not think it means what you think it means.

I'm never sure whether to be amused or saddened when I hear most people talk of "marketing". The problem is that most people had the same understanding of marketing that I did before I got my MBA: marketing is a means to get customers to know about and to like your product. Using that definition, "marketing" is merely a combination of sales and advertising. However, I've come to the conclusion that the most important task a good marketer can do for a company is the one that's most overlooked: finding a way to understand your customers' needs and wants. In other words, marketing research is far and away the most important task marketing will do for your firm.

Why?

A common mistake among people and firms that I've encountered is that they assume that they can meet their customers' needs with their current product offerings. This is true to a point - if you weren't meeting some customers' needs on some level you wouldn't still be in business. But most firms fall into the trap of giving customers what they ask for, rather than what they truly want. This is especially true in IT, when business needs are often overlooked in favor of technical requests. But if you're constantly using marketing as a means to sell your goods before you find out whether your target market wants them, you're setting yourself up to fail sooner or later.

Which is the better search engine, Bing or Google?

Every once in a while I hear the question: Which is a better browser, Bing or Google?  Like most questions like this, the answer isn’t one or the other, but each has its own strengths and weaknesses.

User Experience:

I like clean, simple, and straightforward software.  Applications that do everything under the sun generally annoy me.  Google’s home page is obviously pretty simple.  You see the Google logo (or a variation of it), a search box, and little else of note.  It’s pretty simple to understand.  Bing, though, somehow managed to keep the simplicity of Google but add a background image to the search page with areas that you can learn more about the image.  If you want the simplicity, it’s available to you.  If you want a quick distraction and want to learn something at the same time, Bing can provide that easily too.

Winner: Bing

Searching for numerical information:

If you are looking for prices for airfare, hotels, gadgetry, etc., you’re probably looking at several sites and comparing prices.  Though Google appears to be changing, Google’s primary approach to this situation is trying to give you links to sites that have price comparisons, such as expedia.com.  Bing, on the other hand, has the ability to look at all of these websites, pull the information off of them, and then gives you the best prices based on the times you give it.  No more jumping from site to site trying to get the best price!

Winner: Bing

Searching for qualitative information:

Sometimes, when on the internet, you need to find information that is not easily compared or quantified.  I find myself wanting to search for this type of information often while at work looking up a new technique or trying to troubleshoot an obscure error.  Google has a great ability to give relevant results containing all of the important search terms.  Bing, on the other hand, does a relatively poor job with qualitative searches.  It tends to ignore some of the search terms as it sees fit, and will sometimes correct your spelling without giving you an option to override the correction.

Winner: Google

Searching for my blog

Most of the people that come to this blog from search engines come from Bing.  To see why, I put in some search terms that I thought were relevant to my blog, and my blog was on the first page on Bing.  My blog didn’t appear in the first five pages of results on Google.  I’m not an SEO expert, so I don’t know why, but it’s clear that Bing loves me more than Google does.

Winner: Bing

Conclusion

If I’m searching for anything that can be counted or compared, I use Bing to get the information I need.  Its greatest strength is pulling information from sites so I don’t have to go there myself.  If I’m looking for something more obscure, or if I’m looking for something that would easily be contained on a single site, Google is usually my choice.  When in doubt, I start with Bing, but jump to Google if I don’t see any meaningful results in the first page.

Why User-Centered Design is absolutely vital for the success of your software project

Most custom software I’ve encountered is designed pretty poorly. The primary problem stems from the fact that user interfaces are typically designed by one of two groups: software developers and/or graphic designers. Both software developers and graphic designers play an important role in the completion of a successful software product, but neither makes great interfaces. In general, software developers make interfaces that are easy to create by using idioms that map to the underlying data store. Graphic designers focus on creating interfaces that maximize the initial “Wow!” factor. But in both cases, the interface is typically cumbersome and unintuitive.

Earlier, I had written about how technologists need to know more about marketing. Since needing to know more about marketing is a rather vague goal to strive for, it’s important to know about the next best thing: User-Centered Design, or UCD. What a specialist in UCD does is interviews probable end-users, watches them complete their tasks, and interviews business stakeholders in order to fully understand the needs of the users. Once these needs are met, a User-Centered Designer would create the outline of a software solution that would be easy for the users to understand and more fully meets their needs. It’s essentially just marketing concepts applied to software design.

Typically, a business person looking to create custom software doesn’t want to spend the cost up front necessary for a thorough UCD effort. However, these costs are almost always worth it in the long run. Consider these:

• By having a thorough understanding of the user’s needs, you can maximize worker productivity
• By knowing how the typical user goes about completing their tasks, you can minimize user training time
• By knowing the end-goals of all parties involved, you will minimize the amount of rework after the product starts being used
• By increasing productivity and decreasing training time and rework, you will increase overall satisfaction and acceptance

When put in these terms, it’s tough not to put forth the extra effort up front in order to increase the odds of your project being adopted successfully.

Why software developers make lousy testers

Developers make lousy testers, and I say this both because I’ve been a developer and because I’ve been a team lead/project manager who watched over other developers.  Yet companies continue to expect their developers to QA their own work.  Of course developers need to test their work before giving it to someone else – it’s just too easy to make an obvious programming mistake.  But allowing code to be put into production without a non-developer viewing the code is a bad idea.  Here’s why:

Developers are used to working around problems.  

When I’m testing something I’ve built, I might have made a change that affects several pieces of functionality, but I’ll test items one at a time.  Whenever an unexpected problem crops up in an unrelated piece of functionality, I will make a note of it, but I will work around it in an effort to finish my original test plan.  As a result, I’ve gotten good at working around problems in web sites.  I will do it on third-party sites without thinking.  It means that I sometimes will overlook errors because I forget that the end user can’t diagnose technical problems and work around technical issues as easily as I can.

Developers get used to quirks in their software.  

I’m disappointed to say that I can’t think of an application that didn’t have some quirk in it that I wish were eliminated.  The issue is similar to the one above in that we see an issue, think “I’ll fix it later”, and never do.  After seeing that quirk for a period of time, it just becomes a normal part of the interface.  When this happens, and the user doesn’t say anything, these quirks get to production.  Having a thorough testing by a knowledgeable tester can help eliminate these issues.

Developers focus too much on “does it work”, rather than “does it make sense”.  

Developers are primarily paid to turn a design into working software.  Therefore, their focus is on making the design work, not making the design.  When the design isn’t user friendly, or if the design was done by a developer, user interface difficulties become low-priority to fix.  End-user testing can help eliminate these problems that annoy the user.

Things technologists can do to get the attention of business stakeholders

The issues between IT and the rest of the business in a corporate environment is a popular topic in IT magazines and web sites, yet the problem still exists.  Part of the issue is that business people need to know more about IT. (To start, you can read a blog about needed knowledge for business stakeholders in a software development process here.)  Part of the issue, though, is that information technology professionals need to do a better job of delivering what they promise and communicating technology issues is business terms.  Here are some specific things that, if done by IT, should improve relationships between technologists and general business people.

Under-promise and over-deliver

I can’t tell you how many times I’ve encountered situations where a technology worker or group was completely unable to deliver on promises.  There are many reasons for this, ranging from optimistic estimates to unseen roadblocks to deliberately lowering estimates to impress the “bean counter”.  High estimates can certainly make financial stakeholders nervous, but you can bet that blown estimates make them even more so.  Be sure that you can deliver what you promise.  Plan for difficulties you might not see yet, and resist the temptation to lower your estimates to look better to others.

Avoid the use of technology jargon

Technologists, when surrounded by like-skilled individuals, tend to lapse into tech-speak.  This is fine when the recipient of your ideas understands the jargon.  But only bad things can happen if you lapse into tech-speak when talking to a non-technical person.  Your listener may get annoyed that he/she can’t understand you, or may get angry because he/she feels like you’re intentionally trying to make them feel stupid, or may just stop listening because he/she can’t understand what you are saying.  You get the idea.  When in doubt, when you can’t simplify a concept, be sure your listener understands before moving on.  Your listener may learn something about technology and you may learn something about how to communicate technology concepts effectively to non-technical listeners.

Avoid going into too much detail

One pitfall I fall into often is trying to explain too much of the implementation for a particular scenario.  Sometimes I get excited about a particular implementation method, sometimes I want my listener to find holes in my thought process, sometimes I’m just thinking out loud, etc.  In most cases, though, my listener doesn’t care.  I’m just wasting everyone’s time trying to get them to care.

Know your value

Most developers I know simultaneously overestimate their value to a business as a developer and underestimate their value to a business as a knowledgeable stakeholder.  Their overestimation comes from the fact that developers feel important because they can do things that the typical business person can’t, and so it is obvious where the developer’s value to the business is.  Everyone has value to the business, though, otherwise they would get fired (in any reasonable company).  On the other hand, by creating information systems, developers often see how information flows from one part of the business to another, thus giving them a great background on how the business works.

Treat misunderstandings as your fault, not theirs

Technology professionals often get frustrated with non-technological listeners for a lot of reasons, but these are usually the fault of the technology person, not the listener.   Your listener will pick up on this frustration and think that you are frustrated with them.  Understandings are most often caused by overuse of jargon or going into too many details.  Once you understand this, if you do lapse into jargon, you will be much more apologetic and put your listener at greater ease.

Remember, everyone's on the same team

Nothing is more harmful to any relationship, whether it is personal or business, if you lapse into “us and them” thinking.  Your job is to create software, enable communication through networks, etc.  The business person will likely want to push off problems solely onto you as “computer problems”, but you need to resist the temptation of thinking of business requirements as “business problems”.  Technology can no longer be thought of as a separate department, but instead is an enabler of business as a whole.  All problems are team problems which require team solutions.  If you keep this in mind, professionalism from all sides usually follows.

An experience in poor design

I was in the doctor’s office recently, and I had the opportunity to watch the nurse enter information into the office’s new computer system.  It was a somewhat painful experience.  There was information missing from the last visit and when the nurse went to add a new (and rare) disease to the family history, she couldn’t because the system wouldn’t let her.  I saw the UI over the nurse’s shoulder, and it looked blocky and clunky.  On top of that, several nurses made comments about the new system, ranging from “I can’t get this to work” and “We aren’t as good with the system as we should be, but we’re getting better”.

I’m not blaming the nurses – I saw the system over their shoulders and didn’t like what I saw.  The system was clearly designed by developers who gave more thought into how they could design the user interface to easily meet the functional requirements than how the user interface could most easily meet the user requirements.  The result was a poorly utilized system that was lowering the morale of the staff.

How could the system designers have gotten around this?  System designers must start by getting a thorough understanding of what the end users need.  Not what they want, what they need.   Without this understanding, the designer is forced to make guesses as to what the user needs, and the designer (whether their official title is business stakeholder, developer, or a trained designer) usually guesses incorrectly.  How do we go about doing this?  To start, technologists need to know more about marketing.  In the long term, though, we need to have a better approach than just a generic marketing approach.  Luckily, user-centered design is becoming more and more accepted.  More on that in a future post.

Why the iPad might be the future hardware of choice for the retirement-age user

Several of my retirement-age family members have gotten iPads recently because of their portability and ease of use.  I’m ashamed to admit that I didn’t think much of it until I read this article from the Harvard Business Review (especially innovative idea #3):

http://blogs.hbr.org/schrage/2011/12/six-innovative-ideas-to-watch.html

In retrospect, I wish that I had expanded my mental view of the iPad sooner.  It makes perfect sense.  Add easy screen resizing and large keys to the portability and general ease of use, and you have a great tool for retirement-age computer users in the iPad.  It will be interesting to see who takes advantage of this market with targeted, innovative apps.  It will also be interesting to see if more developers will take iPad development seriously as a result.

Programming without a computer-related degree

I used to be hesitant to admit that I was a software developer, but I didn’t have a computer-related degree.  I told myself that it was because other people might think less of my ability if I admitted that I didn’t have formal training, but the truth is that I felt like my technical skills were less than what they should be without the degree.  After being in the business of software development for a while, I’m convinced that my lack of formal training is actually an advantage.  Here’s why:

As a self-taught developer, I can prove that I can learn on my own

When I first started getting paid for writing software, AJAX didn’t exist, there wasn’t much of a market for handheld device development, few open source tools existed in the .NET world, cross-browser compatibility was foremost in the minds of developers, and Adobe’s Flash was about the only way to create truly interactive web site.  Times have changed.  Certainly there are similarities between what I do now and what I did then, but there are a lot of differences, too.  Software developers who are unable to keep up with the latest technologies will find themselves obsolete in a short amount of time, so the ability to pick up new technologies quickly is vital to being successful in technology.  Because I taught myself how to program, I’m used to the idea of learning a technology outside of my job.  I can learn new technologies relatively easily as a result.

I’m not tied to any particular platform or approach

I’m rather surprised by the number of people in technology who cling to their particular tool of choice, usually for no good reason.  These zealots think that everyone who uses a tool or approach other than theirs are incompetent.  There seems to be a high correlation between people with these attitudes and people with computer science degrees.  (I can understand that point of view – I had the same view repairing band instruments.  I was taught the “best” way to repair an instrument by arguably the best repair school in the country.  Why shouldn’t I expect that everyone else should do it the same way?)  No tool is evil, despite what the technology blogs say.  Some are merely better suited for a particular purpose than others.

When I learn a concept, I’m often able to apply it to a real-world scenario immediately

From the first day I started learning technology, I had a particular problem in mind when studying.  At first, I was studying C++ and HTML in order to create a website for the music store I worked for.  When I realized that C++ was rather outdated for web applications, I used the object-oriented concepts and memory management knowledge to pick up C# and ASP.NET.  My SQL Server certification came after I realized that I needed a better handle on databases in order to create scalable applications.  My explorations into jQuery and Java came when I started finding limitations with ASP.NET.  It might not have been the most efficient way of learning things, but what I learn, I learn well.  And yes, I’m constantly looking to expand my horizons by listening to other developers, even if they do have a computer science degree. :-)

I understand that there’s more to software than just technology

If you read my blog regularly, you knew this was coming.  Software teams will recommend tools based on what makes it easier for them to use, not which one results in a better user experience.  As an example, I once heard a developer claim that every SharePoint project should be started and updated in Visual Studio only.  His reasoning was that by allowing the user to create/update/change whatever they wanted, any particular SharePoint site would be prone to breakage and higher testing and deployment costs.  While he was factually correct in his reasoning (that starting and updating all SharePoint projects in Visual Studio would reduce testing and deployment costs, as well as reduce breakage), his conclusion was developer-centric.  If you know anything about SharePoint, you know that its primary strength for the average user is that it can be updated extremely easily by a non-developer.  He was removing one of the primary reasons for using SharePoint for the sake of his own ease of use.  The attitude of putting user’s needs second to developer ease-of-use is pretty common.  Because reducing software teams’ efforts reduces costs, I’m always conscious of tools’ ease of use, but I always try to keep that secondary to the end user’s needs.

Computer Science degrees aren’t all bad

With all that said, I don’t recommend any young person trying to get into a technology field skip a Computer Science degree.  I’ve certainly met my share of CS graduates who were able to understand the business behind the technology, and there are still places for the tech-centric employee.  I would instead recommend getting the CS degree, but get a second major in a business-related field.  Rightly or not, many hiring managers still believe that software development cannot be done well by someone without a CS degree.  Plus, you do learn a lot of useful information while getting the degree.  The fact that I was able to get the knowledge without the degree shouldn’t minimize the importance of that knowledge.  If you have the degree, be aware that there’s a business world outside of the technology.  If you are a hiring manager, be careful not to take the degree (or any degree) too seriously; it’s the knowledge that counts.

The importance of rewriting working code

Refactoring code, or the process of rewriting code that already works, is a vital part of maintaining the long-term health of a software application.  Most business stakeholders do not wish to pay for this, though.  Most objections I’ve heard fall under two categories:

• Rewriting working code will provide no
• The need for refactoring is a sign that the developer didn’t get it right the first time, and the budget shouldn’t have to suffer for a development mistake

Both of these objections show a fundamental lack of understanding of the software development process.  Refactoring code is more of a software maintenance process; just like getting your oil changed in your car or getting your air ducts cleaned in your house are necessary maintenance.  To see why, take a look at this scenario of what could happen if you don’t maintain your code.  In this example, I'm designing a page that allows users to enter orders for widgets.

Business Leader: We need to show this page to two types of users, Sales and Procurement (who fulfills the order).  Sales people will be able to enter as many orders as they wish, but procurement will only be able to see or edit orders that have been finalized by the sales person.

Pseudo-code:

If User is Procurer and Order is Finalized

Show Page

Else If User is Procurer and Order is Not Finalized

Hide Page

Else if User is Sales and Order is Finalized

Hide Page

Else if User is Sales and Order is Not Finalized

Show Page

This code is already pretty complex and is far from ideal, but it's manageable.

But as users see the system, they realize that they need to make changes:

Business Leader: We need to make sure that orders are completed on time, so Supervisors need to see the page too, but they can’t submit orders.  They can send notes to parties involved and override settings, though.  Sales people need to see orders they’ve sent to procurement.

Pseudo-code:

If User is Procurer and Order is Finalized

Show Page

Else If User is Procurer and Order is Not Finalized

Hide Page

Else if User is Sales and Order is Finalized

Show Page

Make page read-only somehow

Else if User is Sales and Order is Not Finalized

Show Page

Else if User is Supervisor

Show page

Hide finalization capability

Show supervisor-specific controls

Ok, I’ve seen worse.

Business Leader: Supervisors talk to our customers, and we realized that they need to enter sales in as well.  But a supervisor can’t supervise his/her own sale.

Pseudo-code:

If User is Procurer and Order is Finalized

Show Page

Else If User is Procurer and Order is Not Finalized

Hide Page

Else if User is Sales and Order is Finalized

Show Page

Make page read-only somehow

Else if User is Sales and Order is Not Finalized

Show Page

Else if User is Supervisor

Show page

If Supervisor did the sale and Order is Finalized

Make page read-only somehow

Else if Supervisor did the sale and Order is not finalized

(We already showed the page, so we’re good)

Else if supervisor did not create the sale

(We already showed the page)

Show supervisor section

Hide finalization capability

That's quite a bit worse.  You can imagine coming to this code as a programmer new to the project and being confused by this approach.  And keep in mind that the harder the code is to read and understand, the harder it is to make changes without introducing new bugs.  Now, let's refactor:

Get the user that's viewing the page

If user can read page

Show Page

If user cannot finalize

Hide finalization

If user cannot edit

Make page read only somehow

If the user is the order's supervisor

Show supervisor information

In a separate area of the code, you’ll define the method of getting a user like this:

If the user is a supervisor

Get the supervisor information

If the user is a sales person

Get the sales person information

If the user is in procurement

Get the procurer information

Finally, we would define each user separately.  Here’s the supervisor’s pseudo-code as an example:

Can I read the page?

Yes

Can I edit the page?

If I’m the salesperson and the order is finalized

No

If I’m the salesperson and the order is not finalized

Yes

If I’m not the salesperson

Yes

Can I finalize the page?

Only if I’m the sales person.

Am I the order’s supervisor? 

Only if I’m not the sales person.

This code probably looks more complex than the first example.  However, by changing the code in this way, we are hiding the complexity of the code for any given point in time and allowing the developer to only see what's needed at any given moment.  Do you need to see a big picture view of what's happening?  Just look at the top-level code.  Do you need to see what the supervisor can do at a given moment?  That’s pretty easy to do too.  This code is easier to read and edit, making bug fixes and adding new features significantly easier, lowering the costs of maintaining the software significantly.  Also keep in mind that this is a relatively simple scenario.  Imagine looking at hundreds of thousands of lines of code that looks like the last pre-refactored example.  Not pretty!  So perhaps the next time you’re faced with paying for refactoring code, try to imagine maintaining this piece of software for years to come, and think of the long-term health of your software.