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.