Keeping it Simple

In my second year of NAIT one of our instructors decided that we should enter a programming competition put on by ACM.  With more than just a little curiosity we entered the competition.  One of the problems was to print out a multiplication grid, using Roman numerals.  We had a difficult time with this question, but when we finished we had a program that could print a grid of almost any size and convert the numbers into Roman numerals.  It worked, but our instructor was disappointed.  He asked us why we made it so complicated.  All that was asked was to print out the multiplication grid, so why hadn’t we just printed the grid with 12 PRINT statements?

Talk about keeping it simple!!!

Blaire Pascal, a French mathematician and philosopher, once wrote “If I had more time, I would have written a shorter letter.”  This completely goes against “traditional” productivity measurements in IT that state each programmer should generate x KLOC (thousand lines of code) per month:  if you generate more, you are more productive.  Generating more lines of code goes completely against keeping it simple.  The odds are you are cutting and pasting lots of code, doing things in ten lines when it can be done in one and generally doing your best to add fluff to the application.

The next time you are sitting down and writing a method in the language of your choice, check to see the size of the method.  A mentor a number of years ago had a simple rule:  if you can’t see all of the lines of the method on the screen at once, rewrite it.  I have tried to follow this as closely as possible for much of my professional career and have been quite successful.  By, quite frankly, putting in arbitrary limits I have forced myself to think simple.  Sometimes a single method needs to be greater than the height of the screen, but this is an infrequent occurrence.

Keep it simple and you’ll be surprised at how productive you really are!


Striving for “It Doesn’t Suck”

While waiting for the bus I looked across the street and noticed that someone seemed to have written a long essay on the plywood surrounding the construction site.  While I couldn’t read much of it, what I could read was very thought provoking:

… should we be striving for “it doesn’t suck” as our goal?

Is “it doesn’t suck” ever something we should strive for? 

As I sat down on the bus, thousands of images flashed through my mind, all of them related to that comment.  For instance, did you know that of the last 24 toy recalls in the United States, every single one has been related to a product that has been shipped from China?  Due to various pressures, both in the Chinese company manufacturing the toy and the American company importing the toy, the people involved probably thought that “it doesn’t suck” was a pretty good choice.

It doesn’t suck doesn’t necessarily mean that something is good, just that it isn’t bad.  There is still a wide gap between good and bad and it doesn’t suck only covers a small area of that gap.  Now, I will be the first to admit that this problem is not specific to one role within the project.  Everyone, from the project manager to the developer and everyone in between, has to commit to striving for something better.  While one weak link in the chain can have a downward affect on the overall quality of an application, that does not mean that it cannot be remedied.

When I was younger I remember the news talking about the lack of quality of North American products and how products from overseas were better built and cost less money.  Ford started an ad campaign about “Quality is Job 1”.  Much has happened since that time.  Overseas products no longer have the same high regard as they used to (at least some overseas products), but the rise in quality in North American products has not been that great.

The sign of a great company, and great staff, is one where no one strives for “it doesn’t suck“.  The purpose behind all of our work is continual improvement towards something better.  Something good.  Something great.  In my mind, what we should be striving for is “it’s awesome“.

Not just IT

Cross fertilization.  No, we’re not talking about agriculture.  What we are talking about is the ability to look at other areas and bring some of those concepts and ideas into your own area.  Jim Collins talks about this in the PBS show Good to Great when he showed how public sector organizations (for example, a police force) can utilize the tools, experience and lessons from a company such as Starbucks to revitalize and improve themselves  Just because something isn’t in your area of expertise, doesn’t mean that you can’t read it, watch it, enjoy it and, most importantly, learn from it.

For instance, the whole idea behind Design Patterns for IT applications was started by a 1977 book by Christopher Alexander that established a pattern language to discuss the construction of towns and buildings.  It was a book on architecture, not IT.  The idea behind this book is what prompted a number of individuals in the IT field to look at a pattern language for designing applications.

While it is important to understand what is happening in your own field and be proficient at it, there is an alternative need to broaden your perspective and look at other areas in an effort to kick start your own mental processes.  While watching the Bridge to Terabithia with my daughters I was struck by the appropriateness of the song “Keep Your Mind Wide Open“.  While it matched the underlying thematic element in the movie it was also very appropriate for this discussion.

By limiting yourself to just IT books and websites and magazines there is a tremendous amount of knowledge that people miss out on.  By opening up your perspective, by keeping your mind wide open, you expose yourself to new possibilities and new ideas that might, just might, change your perspective on a problem and make something easier to solve, easier to build and better for everyone involved.

Changes and IT

I always find it really funny during playoffs (baseball, basketball, hockey, football, etc.) when people suddenly adopt these superstitions. You know what I’m talking about. The baseball player who refuses to shave because “it might cause bad luck”. Or the hockey player who taps the pads of his goalie in a particular sequence because “it’s good luck”. Or the developer who always does things in a particular way because he’s “always done it that way before and it’s worked“. People don’t like change.

One of the most fascinating things about the IT industry, whether you work on mainframes, minis or PC class servers, is that the technology changes. It doesn’t always change quickly but you don’t always change the course of an ocean liner quickly either. (Although I bet the Lusitania wished that you could.) The process of making steel hasn’t really changed in a long time. Neither has the process for making plate glass. IT? Yeah, it changes.

But you know, change cause problems. Changes require people to learn new things. Changes require people to adapt. Darwin recognized this a long time ago and wrote a book about it, some of which is actually applicable to the IT field. As new technology enters the field it is up to the developer to understand the technology and adapt his personal best practices to the new technology. Yes, you may have done this dozens of times in the past, but the technology has changed and maybe, just maybe, you shouldn’t be doing this in the future.

Unlike Darwin’s theory, failure to adapt will not cause your extinction, but it will limit what you can work on in the future. Embrace the technology and embrace the change. Learn to take your personal best practices and apply them to the new technology. They worked once and they can work again, but you need to make an effort.

Microwaves and IT

I was trying to follow the instructions on the back of the box the other day when I cam to a part that had me stumped.  It said that in order to defrost the item I held in my hands I needed to set the power to low and put it in the microwave for 2 1/2 minutes.  Now, I consider myself to be reasonably intelligent (some may not agree with that statement) and I consider myself to be somewhat of a technology geek.  I like silly, geeky things, but, darn it, I can’t defrost anything in our microwave!!!!

Now, thinking just like the instructions, I set the power to low and then tried to enter a time, but for some reason I was entering in the time for “Step 2” of the overall process instead of Step 1.  So, I hit the “Defrost” button and was asked to enter in the weight of the object in kilograms.  Tossing it up and down like the frozen pork sandwich from Costco that it was, I guessed at about 0.1 KG.  I tossed it in the microwave and crossed my fingers.  I came close but it was probably about 0.15 KG, which I couldn’t enter as it expected only a single digit after the decimal point.  (By the way, the correct method was to enter in the time, then enter in the power setting.  I had this epiphany on the bus on the way to work this morning.)

We sometimes build applications the same way that manufacturers build their interfaces.  it makes perfect sense to one or two people, or even the “study group” that looked at the interface, but when you give it to someone that has never seen it before, has never been part of the privileged few that saw the development process, the interface sucks.  Sorry for the bad news, but interfaces made by geeks are … well, geeky.  They make sense to geeks, some of them,  but honestly don’t make sense to anyone else. 

You see this in many applications and still see it today.  I was looking for an application to catalog by DVD collection using information sucked out of the Amazon.com database.  I found half a dozen applications, but they all looked like they were put together by Picasso.  I then found an application that looked like it was put together very well.  They had the complete package from the functionality that I wanted to a simple, pleasing user interface.

Project Managers, don’t trust developers when it comes to user interfaces.  Look at the designs yourself and see if they make sense.  if you can’t figure out how to do something, get it redone as someone totally unfamiliar with the project is going to be completely lost.  If the response is “the user wants it this way” then this really means that there are too many geeks trying to cook and it might be time to bring in a professional designer to help you out.

Innovation on Demand

I know this is going to bring up painful memories, but it will soon be over.  Imagine that you’re at a meeting where you are discussing some project related issues and potential solutions.  Suddenly your manager says to you, “So, now that you’ve heard the problems, what’s your solution?”  Your mind goes blank as you try to think of a solution to a problem that you’ve never really analyzed before.  You start breathing quickly and shallowly as your heart hammers away at 200 beats per minute and the adrenaline flowing through your system makes you acutely aware of everyone looking at you.  Looking at you with both sympathy and glee, thankful that they were not chosen. 

I am confident that 99% of you have been through this.  The 1% that hasn’t been through this  just graduated and hasn’t had the opportunity that the rest of us have had.

It is widely thought amongst management types that geeks can innovate on demand.  (Boy is that statement going to get me a lot of email.)  This is, however, fundamentally wrong.  Indeed, it is wrong for most people, not just geeks.  In order to proved a good answer to a question the person needs to understand the context in which the question is being made or the issues behind the problem.  By tossing out that one liner about coming up  with a solution with no opportunity to prepare is quite unfair.  The individual in question probably does not have a suitable answer (if they did the answer was so obvious that other people should have realized it) and the added pressure of having to answer this in a more formal meeting environment is going to make the person less likely to come up with a good solution and more likely to come up with a safe solution.

This is not to say that safe solutions cannot also be good solutions, but the odds are that the reason the manager is asking this question is because none of the safe solutions seem particularly attractive.  Managers are traditionally risk adverse which means that they would have looked at the safe solutions already.  Sometimes, however, a Eureka moment arrives and an answer comes to your mind, fully formed and breathing on its own.  The rush, the thrill of coming up with an answer is fantastic.  BUT, don’t expect it.  Expecting it is almost guaranteed to make sure that it is not going to happen.

So, managers, if need to get an answer to a problem in a meeting, don’t single out anyone as that added pressure is probably going to do the exact opposite of what you expect.

Alone in a sea of web sites

Have you ever been to the mall when it’s crowded?  You drive around the parking lot, looking for a spot, but the only thing close to the doors is a handicapped spot.  You look at the vehicle your driving, realize that it is not a handicap and decide to move on.  You eventually find a spot in the same postal code and start the long walk to the door.  On the way you see this little sports car drive into the handicap stall and out pops someone who, other than his driving style, has no handicap.  What he did, and you didn’t do, was take the first available spot to park in.

This is, in many ways, how most projects build their installation applications.  (Yeah, I’m wondering how I’m going to connect the two myself, but hang in there for a couple of minutes.)

Many development projects have their own servers.  These servers are isolated in that no one else uses them and the project teams can configure and administer them any way they wish.  Once they are ready for UAT, however, they need to leave this isolated environment and enter the world of the Shared Environments.  On these servers there are multiple web applications and, drum roll please, multiple web sites.  Many setup applications are designed so that they install in the first web site they come across (much like parking in the first parking spot they see).  This is such a bad idea that I shudder when I write about it.

Applications need to understand that they co-exist with many other application.  Indeed, they are running on a server that has at least one web site and probably more.  During the installation process the web application should enumerate the web sites that are available and ask the person installing the application under which web site it should be installed.  Much like asking which directory to install an application into, the web site to install into is just as important, if not more important than the physical location of the files.  If the application just blindly installs itself in a web site the Deployment Team will quite often need to move the web application between web sites and, hopefully, everything moves over properly.  Nothing like crossing your fingers and hoping that something works.

So, please, in the future, change your web application installation programs to enumerate the web sites and ask which web site the application should be installed under. It’s either that or I start leaving nasty notes on your windshield.

So, when is it going to be fixed?

“So, when is it going to be fixed?” Have you ever screamed when someone has said this?

About fifteen years ago the company I was working for had just replaced the biggest application that they used. After a number of months of daily fire fighting the system had begun to stabilize and the number of daily data fixes was down to handful. I came in to work, sat down at my desk and immediately had half a dozen people asking me to help them out. It appears that our application was no longer responding. Literally the eighty percent of the organization that used this application on a daily basis was unable to use the application. Off we went to investigate the problem.

About an hour later, when I was walking down the hallway my boss asked me “So, when is it going to be fixed?” I told her that we didn’t know what the problem was so I couldn’t tell her. She kept pressing me for a time commitment as to when it would be fixed and I kept telling her that when I knew what the problem was I would know how to fix it and I could then tell her when it would be fixed. She kept pressing me, however, until I finally snapped … and just walked away.

There is an important lesson here to both management and the people trying to resolve issues. For management, if the people who know the most, don’t know what the problem is, they cannot tell you when it will be fixed. It’s as simple as that. Come up with an answer that conveys this to your clients because you’re going to be using that same phrase a lot throughout your career. For people trying to resolve the issues, if you don’t know what the problem is, don’t give a time estimate because all you’re doing is lying to them and to yourself. Tell them you don’t know what the problem is. There is no shame in that. You don’t walk into a Doctor’s office and expect him to have an answer right away, so why should they expect you to have the answer?

Again, What’s the Problem?

When I look back at yesterday’s comments about defining the problem, I can find many instances in my career where, if I had stopped and examined the problem in more detail, I would have made different decisions and different recommendations.

With regard to technology decisions, I’ve usually made the right recommendation at the right time based on the information I was given.  I was asked to solve a specific problem, within specific parameters, and I came up with a solution for that problem.  The problem lies in the fuzzier “direction” requests and anything else that involved other people making decisions.  You see, I am really bad at guessing at what other people think.  I just can’t do it, mainly because everyone else thinks illogically.  (Either that or I am insane.)

When dealing with other people, however, it is more important than ever to sit back and really understand what the problem is, not just your solution to the problem. Everyone has a different perspective on the issue and everyone is going to have a different answer to the problem.  If we can agree on what the real problem is, however, we can more readily agree on an overall solution that fits in with everyone’s perception of the problem.

Whether the problem is with regard to a complex business issue or a procedural flaw in a process, the underlying problem needs to be identified and agreed upon by the different parties.  You may discover that what you are trying to solve isn’t really a problem, but a symptom of a completely different problem that is not going to be resolved by your solution.  Implementing your solution would do nothing to fix the problem, which in itself is a problem, just not the one that needed solving when you started.

What’s the Problem?

In the IT world we are sometimes enamored with a solution and try our best to implement it, regardless of the actual problem.  This is the infamous “solution looking for a problem” syndrome.  People who are particularly attached to a technological solution sometimes fail to understand that their solution, while perhaps elegant and sophisticated, just won’t be effective in the long run.

There are many examples of this throughout history, but in no industry does this show up more than in the IT industry.  We geeks love our toys.  We love our toys so much that we think they can solve every problem.  Even problems we don’t have.  We create components in which 80% of the code is never executed because no one uses that functionality.  We create processes that are large, cumbersome, and built to handle every possible scenario even though something smaller and faster would handle at least 80% of our work.  We put in checks, balances and counter balances in an effort to ensure that something, somewhere is “done right“.

Although self monitoring is something which is very difficult to do, I think we all need to step back and look at things from a different perspective to see if we are actually solving a problem that needs solving.  The next time you are proposing a solution to someone step back and ask yourself “What problem am I trying to solve?”  Is this actually the problem?  Are you tackling a symptom instead of a problem?  Once you are convinced that you have the problem defined correctly, write it down on a piece of paper and then come up with a reason why you are trying to solve that problem.  Is this reason something that the organization would agree with?  Does it provide a net benefit to the organization?  (i.e. Does the cost of implementing the solution outweigh the benefits?) 

Lastly. take a look at your solution and see it it is actually trying to solve the problem for the reason you stated.  For straight forward technological problems the odds are pretty good that the solution matches the problem.  Once you start moving towards the fuzzier areas of standards, processes and procedures I am sure that you will find that quite often the problem, the reasons and the solution don’t always match up.  If you aren’t sure whether or not they match up, ask someone else to check your reasoning.

Problem definition and problem resolution are basic things, but they are sometimes hidden in the tempting glare of gradients, 3D combo boxes, AJAX and web services.  Put on your sunglasses and see if you can really see the problem.  Chances are you might surprise yourself.