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.

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?

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.

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.

A World of Difference

There is a world of difference between maintenance and development projects.  NOT!!!!

OK, this may be a controversial topic, or it may not be, but I think I need to put some parameters around my comment.  In my mind, the actual act of developing a new application, doing a major enhancement to an existing application, doing a minor enhancement to an existing application or doing a bug fix for an existing application are fundamentally the same with regard to the tasks that need to be accomplished.  How the organization wishes to perceive them, from an accounting, management or accountability perspective may be different, but the same process need to be accomplished.

Whether the scale of the work is large (project) or small (bug fix), the developer still needs to have some requirements, do some coding, do some testing (really important step) and promote it to the next environment.  How the Project Manager (remember this isn't necessarily a title, but a role that someone plays) organizes these tasks, reports on these tasks and celebrates the successes with the team (you do this, right?) is up to the Project Manager.

Some organizations have an arbitrary limit of xx days of effort means a project.  Or perhaps there is an accounting limit of $yyy,yyy dollars is operating (maintenance) but anything over is capital and needs to be a project.  But you know what?  If it takes xx-1 days or xx+1 days, from a developers perspective there is no difference.  If it takes 19 days (maintenance) to add a feature to an existing application or 21 days (small project) to add that exact same feature, the developer is doing the same work.  The processes that the organization asks for may be different, the documentation requested may be different, or perhaps it is who pays the bill that is different, these are all things that surround the core act of development, but should not impact it.

If you feel that I am wrong, please let me know, although based on previous notes I don't think anyone reading this has any qualms about letting me know that they disagree with what I am saying.

Old Programs and Children

I used to believe, when I was younger, that the programs that I wrote would last forever.  They were well written (of course), full of useful functionality (of course) and they could adapt to anything (of course).  Wow, was I disillusioned in a hurry. 

It wasn't that they weren't well written.  I got a phone call from a company, six months after I left it, and it was one of the developers calling me up to thank me for having written the program and the exception handling in such a way that he was able to solve a problem in five minutes instead of the five hours he was expecting.  I was thrilled with that comment.  It was only after I hung up that I realized that it shouldn't have died in the first place, because I could have written it differently so that the information it was looking for could have been found in a more dynamic location.

When we are writing our little part of the overall project, or perhaps we are writing the entire application, we become quite protective of our child.  Anyone that criticizes our application is not worthy of further attention from us.  We close our eyes and forget the flaws of our child and emphasize the good points.  That's not to say that there aren't flaws, but we are so caught up in the entire development of this application that we are sometimes blind to it's faults.  This is not a bad thing!!!!  This bond that a developer forms with the application makes them want to do a better job and makes them want to ensure that everything is done right.

What we, as developers, need to do, however, is step back from being a parent and objectively listen to other peoples comments.  This is probably the hardest thing to do for a real parent and it is no less difficult for you and your virtual child, but it needs to be done.  No one's application is perfect and being able to understand that a critique of your application is not a critique of you as a person is a vital step in being able to be passionate about your work, but realistic about it flaws and weaknesses.  Your virtual children will be better for the effort... I guarantee it.

Constants to the Extreme

Those good old days of COBOL. Yes, it's that dusty old memory trail. Many things can be learned from those days, including what not to do. Not everything was sunshine and roses.

Sometimes people who really didn't understand the technology were allowed to make technical decisions. Worse still when that person was a project manager. The suggestion brought forth was that in many cases you did not need to use an explicit number for a loop, you could set the limit as a constant, so if it ever changed you would only have to change the value in working storage. The non-technical manager extended this to say that you could only use constants

For example:

    PERFORM VARYING ProvinceNum FROM LT-ONE BY LT-ONE
         UNTIL ProvincName(ProvinceNum) = Province OR
               ProvinceNum > LT-THIRTEEN
    END-PERFORM

You can see that this looks like someone got carried away. In this case there is no need to make '1' a constant as it will always be '1'. The key was actually in LT-THIRTEEN. This should have been called MAX-PROVINCES or something else. This would have made the statement look like this:

    PERFORM VARYING ProvinceNum FROM 1 by 1
         UNTIL ProvincName(ProvinceNum) = Province OR
               ProvinceNum > MAX-PROVINCES
    END-PERFORM

The same thing can be said for Visual Basic, C#, Java and many other languages. Not only does judicious use of constants make the code easier to understand, but it makes it easier to change. By making it LT-THIRTEEN, you couldn't very well change that to a different number, so you would have to change the code, totally defeating the person of making it a constant in the first place.

Frequently Asked Questions

No, I'm not going to answer some frequently asked questions. Instead I'm going to make a plea, once again, to the project teams to create an FAQ.

I did get some notes from people complaining that the software (SharePoint) was not a "real" wiki package and they weren't going to do anything that didn't involve HTML markup. A couple of other people complained that the process seemed too difficult and that there was no easy way to enter the data. The odd person mentioned that their application is unique as all of the questions asked were unique and that nothing was frequently asked.

Please, sit down and think about all of the questions you are asked for your project. Have any of them been asked more than once? if so, it is a candidate for inclusion on an FAQ for your project. Summer is coming up and you don't want to be one trying to answer questions that the person across the hall normally answers, and neither do they want to answer questions that you normally answer. Save a life, give some information.

Another war story ...

One thing I do have to admit, and not just for Peter Ford's sake, but for my own, is that growing up in a mainframe world was quite beneficial. The rigor and thoroughness that was required was very good at helping new developers out.

When I was younger I was involved in a project that was creating some stored procedures for a database. The stored procedures were written in COBOL as the database was mainframe oriented and this was the preferred method for writing stored procedures. (We didn't have any PL/1 expertise so that and Assembler were out of the question.)

Because of the mainframe orientation we followed all of the rules that we normally did for COBOL programs. We documented changes that went in, both in the program and in the source control system we were using. This allowed anyone, at any time, to take a look at the changes that had been made to a stored procedure (COBOL program) and see how it had grown.

The same discipline, however, does not seem to be there in the non-mainframe world. Call it "freedom from the tyranny of those mainframe ..." or call it a "more relaxed development atmosphere" or whatever you will, some of the lessons learned from decades of mainframe usage and discipline are still valid in the Wintel era. One of those valuable lessons is putting comments in your code, whether that code is VB, C#, or T-SQL. Comments help identify what has changed in the script. These comments not only help when debugging issues, but could lead to identifying other issues, such as maintainability, that need to be addressed sooner, rather than later. (If the same lines of code are constantly being changed, perhaps that section should be refactored.)

Why bring this up? Well, the vast majority of SQL scripts that I see migrated through DeCo do not contain comments and, quite frankly, this worries me. If we don't know what changes we've made, how are we ever going to know what to test? How are we going to know what may or may not be working?

Kids and Darwin

Recently I was watching The Colbert Report and one of his guests mentioned the fact that he didn't teach his kids all the rules that you need to follow, but he taught them the framework under which those rules exist. For instance, you teach the child that warm wet things (like tongues) have a tendency of sticking to very cold things like metal. You don't itemize the complete list of metal objects like: mail boxes, soccer posts, cars, lamp posts, bus stop posts, fire hydrants, handrails, flag poles, bike racks, chain link fences, etc. You teach them the framework and they get to interpret each circumstance on their own. Darwinism at it's finest.