Reflecting on How Programming Has Changed

My birthday was a few weeks ago. That got me nostalgic and I started thinking about how much has changed since I started programming nearly 25 years ago at Arthur Andersen. I also realized that many things really haven’t changed. And that, unfortunately, we do seem to have to learn the same lesson.

The Internet

Easily, the biggest change is the existence of the Internet. There isn’t an aspect of programming the Internet hasn’t helped. In thinking back, one of the biggest impacts I think it’s had is making documentation and assistance easily and readily available. In my first decade or so of development, if you had questions, the only sources tended to be finding the manufacturer manuals (yes, I have read many IBM COBOL manual) and, if you were lucky (or maybe not so lucky), the corporate “expert”. Now, documentation is readily available on-line and there is tons of help.

REST Programming Architecture

Designing programs using a REST architecture has started to become very common for good reason. However, when I look back, I don’t think REST is a big change. Instead I think it has made incremental improvements over what was learned programming mainframes 40 years ago.

I started as a COBOL, CICS programmer. CICS used an architecture called pseudoconversational which meant that the program serves requests from the terminal and then shuts down. Sound familiar? It is an “old-fashioned” REST architecture. Granted the responses provided are much more limited in CICS than in REST. But CICS was created more than 50 years ago and was revolutionary in how many people it allowed a single mainframe to support.

Open Source

Open source is a great thing; it impacts so many areas of programing and computer use. Open source has been around for decades though. CICS, the forementioned IBM product started life as an Open Source program. What has changed with open source? It is the Internet making Open Source programs and utilities readily available and making it just as easy to contribute.

Programming Languages

Tons of new programming language have come on the scene. Many new capabilities have arrived with them. When I started, procedural programming languages were about it. There was some variation, but the capabilities and the way things were accomplished were pretty much the same in most languages.

Now, we still have some procedural languages though their role is much smaller. Additionally, we have object-oriented languages, functional languages, dynamic languages, and more.

This is the area that I feel has improved the most since I started programming. The improvements in encapsulation and abstraction are nothing short of fantastic allowing us to build more complex systems without making the coding becoming more complex. In fact, in many ways, I believe systems today can be simpler to understand than equivalent systems from 20 years ago because of the extensive encapsulation and abstraction support in modern development languages.

In Conclusion

Being a computer programmer today is vastly different than it was when I graduated college. I wonder how different it will be when I look back in another 20 years? Will we be looking back on the quaint days of object-oriented and functional languages the way I’m looking back at procedural languages today?

Comparing Android and Apple iOS

I’ve had an Android phone for nearly three years now. A few days ago, I bought an iPad. I can’t help but compare them when I use them. So I thought I’d write an article on the differences I see. I’m also going to mention the differences I expected but don’t see.

I’m going to try and avoid things that are better on the iPad because of the larger screen. For example, surfing on the iPad is much more pleasant but that is mostly because of the much larger screen.

Also, my Android phone is a T-Mobile G2 phone running Android 2.2. This phone is vanilla Android; it does not include any of the crappy interfaces pushed by some of the phone manufacturers.

General Interface Stuff

I’ve heard that iOS is more polished than Android but didn’t really believe it. Yes, Android has some inconsistencies and some annoying behavior but overall it was pretty good. Now that I’ve used my iPad for a few days, I believe it. The polish shows throughout the whole product:

  • The interface is more consistent app to app (considering the bundled app’s)
  • The interface for settings is consistent setting to setting
I think this makes iOS devices easier to learn than Android devices.

Winner – Apple

Touch Screen

Just like the refinement, I’d heard that the Apple touch screens were superior but didn’t really believe it. My Android touch screens are responsive and easy to use. But after using the iPad, I definitely agree that the Apple touch screen is better.

I don’t know if the improvements are because of the hardware, software or both but the iPad is definitely a more responsive screen.

Winner – Apple


The MobileMe app included with the iPad is really nice. It lets you see where your iPad is (assuming it is on and connected), let’s you remotely wipe your iPad or iPhone, and is integrated right into the device. Android does not include anything comparable.

Winner – Apple


I have big fingers and find typing on touch keyboards tough. From what I can judge, Apple’s keyboard is better than the default Android keyboard. I think this has more to do with design and the better touch screen than with the form factor.

However, Android allows third-party keyboard app’s. And that means, you can get an Android device with the fantastic Swype keyboard (which is on my G2). Swype is the best touch keyboard I have ever used. It is easy and fast to type on. I never use the physical keyboard on my phone because the Swype keyboard is better. And it is easier to use than the iPad keyboard.

If you ever have the opportunity to try a Swype keyboard, take it. You will be surprised how easy it is to use.

Winner – Android

The Hardware Back Button

Most Android devices include a back button implemented in the hardware. This button returns you to where you were previously.  For example, if you opened the browser by clicking on a link in an email, the back button returns you to the email. A much better description of the hardware back button functionality can be found on the Bump Developer Blog.

I find myself looking for that button on the iPad. The iPad lets me do the same thing via the task bar but it just isn’t the same.

Winner – Android

Email Accounts

I’m a big Gmail fan. The Priority Inbox functionality added about a year ago is a big leap forward  in helping me manage my email and I use it regularly. That leads me to my dilemma.

Android incorporates Priority Inbox into it’s Gmail client. I don’t like the iPad email client because it doesn’t integrate Priority Inbox. But, for other email accounts, the email clients are similar and both are capable. Both include solid Exchange support and good support for regular email accounts.

The one other difference between the two is how they manage contacts. With Android, Gmail contacts automatically show up as contacts in the phone. If I make a change to a contact, the change will automatically sync with Gmail. With my iPad, I have to sync contacts through iTunes.

Winner – Android 


I’m not an iTunes fan. I installed it on my computer for the first time in a long time because I had to for my iPad. Why can’t Apple make this a better product?

Android, on the other hand, doesn’t force you to install any software. That also means Android doesn’t provide a way to sync content nor does it provide a way to backup your device.

Winner – Apple (barely)

Android Store vs. Apple Store

I had heard a lot about the Apple Store and how much better it was than than the Android store. So far, I don’t agree with that. I feel that the experience in the stores is about the same. And both stores need to improve.

Winner – Draw

Installing App’s from the Store

Installing applications from both stores are simple processes. Both devices have some quirks though:

  1. Apple forces you to reenter your Apple ID password every session you install applications from the store even if the app is free. I think this is a pain. And it’s enough of a pain that I’m thinking of changing my password to something simpler.
  2. When you install an app from the Android store, the second step is a page that informs you what resources the app will use. Sounds like a good idea but the execution stinks. I  believe these pages display but are never read.
  3. When you purchase app’s (as opposed to free app’s) from the Android store, the flow is different. The Apple approach is identical (which, I realize, is probably the reason for reentering your Apple ID password) regardless of whether you are paying for the app or not. The Apple approach is much better.

Winner – Apple


There are a few things I didn’t cover. First, I didn’t talk about the browsers because the iPad is better to surf on because it is bigger. And I felt that would prevent me from any type of objective comparison.

Second, I didn’t talk about Flash support because I don’t think it matters. My G2 includes Flash support but I haven’t installed it. And I don’t think it is a very big deal.

Overall, I am happy with my Android phone and my iPad. Each has it’s own strengths and weaknesses and both work great. It will also be interesting to see if Apple can hold it’s lead in the phone and tablet arena.

Epsilon Security Breach

Since my last post on the Epsilon Security Breach, the impact of the Epsilon security breach has gotten bigger. In fact, in an article posted on Yahoo news, a Reuters news writer stated:

In what could be one of the biggest such breaches in U.S. history, a diverse swath of companies that did business with Epsilon stepped forward over the weekend to warn customers some of their electronic information could have been exposed.

So the breach has grown since it was first announced last week. I wonder if this will get bigger  since the same article goes on to say:

“While we are cooperating with authorities and doing a thorough investigation, we cannot say anything else,” said Epsilon spokeswoman Jessica Simon. “We can’t confirm any impacted or non-impacted clients, or provide a list (of companies) at this point in time.”

The problem for Epsilon seems to keep growing. As developers, we need to remember this because the last thing any of us want is to the be developer responsible for letting the hackers in.

Security Has to Be Job #1

It’s been a busy week for security administrators. First, the Lizamoon attack last week. Then, data was stolen from Epsilon.

LizaMoon Attack

I first started reading about Lizamoon last Friday (4/1/2011). I was wondering if it was an April Fool’s joke but quickly discovered it was not. Depending upon what estimates you read, Lizamoon infected between 100,000 and more than 1,000,000 pages. In my opinion, the worst part of this attack is that it should have been prevented.

According to WebSense:

We were able to find more information about the SQL Injection itself (thanks Peter) and the command is par for the course when it comes to SQL Injections.

While the attackers did escape many of the characters to make it difficult to decipher what they were doing, SQL injection attacks are easy to prevent:

  1. Run your web application under an id with limited privileges.
  2. Use parameters in all SQL statements. This alone would have prevented this attack.

I found this attack disappointing. I remember reading about SQL injection attacks more than 5 years ago along with how to prevent them. How can we have come so far as an industry but still have so far yet to go?

Epsilon Attack

Sometime last week, Epsilon was attacked and had data stolen. I first heard about this when I received an email from BestBuy Reward Zone which included:

On March 31, we were informed by Epsilon, a company we use to send emails to our customers, that files containing the email addresses of some Best Buy customers were accessed without authorization.

We have been assured by Epsilon that the only information that may have been obtained was your email address and that the accessed files did not include any other information. A rigorous assessment by Epsilon determined that no other information is at risk. We are actively investigating to confirm this.

I received a similar email from Chase today. And, according to Engadget, more companies than these two had their data stolen:

A rigorous investigation has concluded that no other personal data was exposed, however it’s not just TiVo that’s affected — other big names, such as JPMorgan Chase, Citi, US Bank, Kroger, and Walgreens have also seen their users’ deets dished out to the unidentified intruder.

The good news is that only names and email addresses were stolen; there was no information stolen that would lead to monetary or identify theft.

But think about what this will do to Epsilon itself. They haven’t published how the hackers got in and stole the data and I could argue that they shouldn’t.

But hackers did break into their systems and steal data. They had to issue a press release stating as much. And, the impacted companies are blaming Epsilon for the security breach as they should. I wonder how much this will hurt Epsilon’s reputation and market share.

So, What’s Next?

The Lizamoon attack was caused by developers not accounting for SQL injection attacks in their code.

We don’t know what was the underlying cause of the Epsilon attack. From the press release and the apology emails being sent out, I think it’s safe to assume it was an exploit as opposed to a social engineering attack. That means it was probably either a developer-created security hole or operations falling behind on patching servers (or both).

So how do we prevent these types of attacks?

First, I think we as developers need to take more ownership of these types of problems and do more to prevent them. The problem with this is that we’ve heard this all before. And many of us do take ownership and work hard to insure our code doesn’t have any exploits. But a lot of us don’t.

Second, we need to educate our management so that security gets taken seriously. If we do find an exploit in existing code, fixing that exploit has to be a top priority. I bet that isn’t always the case. The problem is the risk and that is, I believe, the key to getting management to increase the priority of fixing exploits; by talking about what would happen if the exploit is found.

Third, we need better tools to help us determine if our websites are secure. Most of the tools that I’m aware of do code analysis and are looking for exploits within our code. That doesn’t help us in these cases because the exploits are in how our web site is working and not in how our code is working. Hopefully some good tools will come along shortly and will help us in this area.

>c# and Brackets

>c# uses a lot of brackets. But there are times when you don’t need brackets; specifically when you only have one statement to execute in the loop/if statement. You have to use brackets when you have multiple statements inside the loop/if.

I do think though, there are times when you should use brackets even though the language doesn’t explicitly call for them.

Specifically, when I have nested loops/if statements, I use brackets on all but the innermost structure even though these aren’t required. The c# language reference for if-else uses the following example:

int x = 12;
int y = 18;

if (x > 10)
if (y > 20)

I would never write that; I would automatically add brackets around the outermost if:
int x = 12;
int y = 18;

if (x > 10)

if (y > 20)

Why? I think the first structure is more error-prone. Also, the simple addition or removal of an else can imply one thing while another thing is happening. For example, what if the first block was rewritten this way:

int x = 12;
int y = 18;

if (x > 10)
if (y > 20)

This makes it appear that the else is associated with the first if statement but we know it’s not. Visual Studio’s automatic formatting should fix the formatting eventually. But until it does, the visual appearance doesn’t reflect how the code runs. And that can cause bugs that are hard to find. So I will continue to always put in the brackets because there is nothing worse than bugs that can hide in plain site.

>Shutting Things Down

>This isn’t a post about technology or about development; it is about the emotional toll getting laid off can take. As you can probably guess, I’m getting laid off a the end of December. Having been lucky enough to have gotten through more than 20 years without being laid off, I’m surprised how much this is weighing on me emotionally.

In addition to the lay offs, the company is transitioning to what I’d describe as a holding company at the same time. As of January 1, it will no longer have any staff or conduct any business. From an IT perspective, this means turning off all IT services and systems at the end of the month.

I have known this change was coming for a few months now. I thought that know would make dealing with this easier. I was wrong. When I’m up late at night, I start thinking about all of the work we did over the past eight years and how it must have no value. After all, if it had value, wouldn’t it be kept?

I do know this isn’t the case. The work we did provided tremendous value. It allowed us to compete with much larger players and let us force some positive changes in our industry. That’s something we need to be proud of.

I also know that the decision to shut down operations and lay off all staff was not a personal one. The company is changing because it had to. We were at a point where competing was more difficult and more expensive. Something had to change.

A while back, I read (sorry, I’m paraphrasing because I can’t find the source for this quote – if you know the source, please let me know):

Behind every business decision that forces personnel changes are people feeling the personal impacts of that decision.

In other words, the fact that I am losing my job makes the business decision personal to me. In an odd way, this makes me feel better; it validates what I’m feeling and makes me believe what I’m feeling is normal.

I know I will get through this and will come out the other side a stronger and better person. But it is not a fun road to go through.

>User Interfaces Are Complicated

>I’ve been doing some work on a food diary site of mine. One of the items I capture is the time food was eaten. I never thought capturing time in a user interface was so difficult until I started to work it.

My first step was to figure out what I needed to capture. I decided I didn’t need an exact time; rather, an approximate time would be good enough (within a 15 or 30 minute window). I looked for a jQuery plug-in to do this. I found some that used drop downs to capture hours, minutes and seconds. I found some that used spinners. I didn’t like any of those.

I found a couple that provide a type of drop-down (more like an auto-complete than a true drop-down) and I liked that approach. But none of them were quite what I was looking for so I spun my own. So far, it’s okay but I still need to do some tweaking on it.

I decided to make a mobile web version of the site. After doing some research, I decided to create the mobile version using jQuery mobile. It’s feature set is pretty cool and it seems rather stable even though it is only an alpha release.

Then I got to time entry. For my control, I display a scrollable Div below a textbox so that time can be typed in or selected. When my scrollable Div displays in phone browsers, it displays but it doesn’t scroll. Plus, given the assumptions I made about data entry, the approach really doesn’t work for phone/touch based browsers. For example, when you hit tab or click on the next field, the scrollable Div autohides. But, who clicks tab on a phone? And because of the window size, it’s hard to click on the next textbox. So the approach that works decently on a computer browser, really doesn’t fit the mobile browser.

For now, I pulled back on the mobile version of my site. While jQuery Mobile is really slick, there are a few too many things missing. Though I did decide that, when I’m ready, I’ll do the date and time with spinners like Android does it natively (separate text boxes for each entry item with the up and down arrows above and below the text box respectively.

It’s amazing how complicated a single user interface element can become.