The Curse of JavaScript: Avoid the powertools until you understand the drill bits.

If I were a gambling man I would bet that everybody that has or is developing using JavaScript (today that is probably all if not most web developers) has started out one day by copying and pasting some script from some site that did something fancy such as a calendar or some nifty navigation menu. I would also bet that many JavaScript developers today still do that – even after many years of JavaScript development. See JavaScript is this funny little misunderstood language that started out back when the industry called it “DHTML” i.e. making your website a little more dynamic and interactive like desktop software. Today we don’t call it “DHTML” anymore since that is not as sexy as the terms “rich”, “web 2.0″ and “AJAX”. JavaScript succeeded in fusing itself to tons of online applications, across different industries, and both enterprise and consumer.

The problem with JavaScript really is how most web developers stumbled across it i.e. copying and pasting it from some other site. Unfortunately many still do that today which usually results in fairly poor JavaScript architecture and implementation. Any web developer worth their salt knows JavaScript, but they also don’t know JavaScript. It just became a common expectation that everybody can do it and as a result very few actually do it well.

Now we introduce all these JavaScript libraries and toolkits – mainly the ones that are easier to learn and also facilitate the copying and pasting. I’m pointing my finger at toolkits such as jQuery, Prototype, and These are all great tools that make building web apps so much more productive, however these tools are also a curse.

These tools made it so easy for anybody to whip up some cool DOM manipulations and fancy Ajax loaders with little to no understanding of what is actually happening in the DOM nor within JavaScript code itself. You just needed some programming knowledge just to manage to hack and slash at it a bit and you end up with something awesome. Maybe you are wondering “but who cares Nael? I just need that feature for my site” and that is exactly the problem. Once you go down this path, it is pretty hard to do it otherwise when you are building something much bigger than a site with fancy navigation. What ends up happening this way is you eventually end up with a dozen different widgets and scripts from different vendors and other sites and you have no idea how they all interact together and what any of them are actually doing. Are they impacting page load somehow? are certain objects colliding with each other? But also the worse problem is you end up confusing the framework with the language. I have interviewed professional web developers that use jQuery who could not explain how $(“#some_id”)  worked but they just know it does. And that is just a simple example – just for that I would not hire you on my team.

I think today JavaScript is probably the best language to learn for anybody trying to get into web development. It’s simple enough to get you started today with nothing more than a browser and a text editor (both you already have on your computer). Also with the hundreds of open and available APIs you can build a ton of cool stuff without even figuring out how to install a database or even a web server. My advice for you is:

Forget the toolkits until you have seen the bad parts of JS
It is so easy to jump into jQuery or another toolkit, but you won’t learn JavaScript. You will learn jQuery and on your next project that is using something else you are SOL because you don’t know JavaScript.

Forget the toolkits until you have discovered the good parts of JS
There are a lot of great parts of JS that allow you to produce fairly powerful and flexible code patterns. Once you understand “this” and “closure” and can develop your own closures and high performance JS application you know you are almost ready for the toolkits.

Forget the toolkits until you have discovered that JS is a functional language
 The great thing about JavaScript is that you can go from an imperative style where statements change state to a functional style. When you start your learning you will start in the imperative style with global functions all over the place. Slowly you move onto the imperative object oriented style. But finally when you understand that everything is actually an object -even functions themselves- and that you can combine and mix objects together on the fly during execution then you can start looking at toolkits. Only then will you understand how all these libraries and toolkits such as jQuery, Prototype, Dojo, YUI, Sencha and tons of others work and only then can you really say you know JavaScript.

As a side note, but I’ll leave this for another post – beware of the magic black boxes that generate JavaScript for you just because you would like to avoid learning it. Its best to leave learning these power tools once you have understood the drill bits.

Posted in front end architecture, Software, web apps | 1 Comment

How to: Google Docs Form with Multiple Spreadsheets

I caught a question on Twitter today about Google Docs Forms and Spreadsheets:


I have been sharpening my skills in the art of Spreadsheet-itsu the past 3-4 years through little challenges like this from work or elsewhere.

So the answer to the question is yes you can:

  1. Create your Google Docs Form
  2. Open the workbook that backs your form and insert a new sheet ex. Sheet2
  3. Use formulas to populate the other worksheet, remember to copy the formula across the whole column.
Above we just pull the data from Sheet1 and populate Sheet2 as well. We can then extend this to build in some logic into the subsequent worksheets. For example I can use this formula to populate my second sheet only with the rows where “Female” was selected, and then have another worksheet for when “Male” was selected. Formulas like this can help me break down the data and look at some underlying patterns easily.


One issue I couldn’t get around was that every time a new record was submitted into Sheet1 from the form, that record was missing from the subsequent sheets. What happens is that every time the form gets submitted, Google Docs inserts a new row into your spreadsheet which ends up shifting your row index in subsequent sheets. Ex. below, what used to be my 9th row became started to reference data from row 10 in the form’s worksheet after the form was submitted –  so I’m missing data from row 9.

Sheet 2 Row 8

Sheet 2 Row 9

I could not figure out how to get around this – but there probably is a way to resolve this. I guess the temporary solution is to recopy the formula across the columns  before you start analyzing the data in the subsequent sheets.

Posted in Google, how to | 2 Comments

What can ant colonies teach front-end architects?

I just read a great article on Embracing Complexity by the Harvard Business Review and I got a crazy idea about using the same “ant colony” metaphor to describe UIs design and architecture.

Image from

There is a lot to learn from an ant colony and these lessons can be applied to many complex problems as the article describes. It is difficult to understand how an ant colony works if you just look at the individual ants. Just like in a complex system, you can’t fully understand it by simply looking at the individual components.

A great lesson from these ant colonies is that ants don’t get the “global system” however their local interactions results in this complex system; the ant colony. Nature is full of these complex & adaptive systems that just work; no leadership; no congress; no committee to make decisions. However us humans like to think of things as “cause and effect” and in software engineering this translates to “sequential programming”. We look at the systems we are trying to build as a chain of steps; doStep1(); doStep2(); etc. We need to break out of this cause & effect paradigm. We can take this a step higher and even compare this to the most popular software engineering process; the waterfall.

We can look at application user interfaces as complex systems that is broken down into individual components that communicate together in the “local” context i.e. the current user view. The whole is greater than the sum of the parts. These applications we are building are really event-driven just like any system that exists in nature. Decisions lead to cascading events. A user clicks on a button, some components choose to respond to that event. Or the server emits some signal that some other components would choose to respond to.

So how do you take these lessons from an ant colony and apply it on your next UI project? Think events, stop thinking functions.

  1. Break your UI into small components and widgets with related functionality
  2. Use the publish/subscribe mechanism within your framework. You can have a look at my post about Dojo’s Publish and Subscribe.
  3. Design your components to communicate with each other using events. Widgets communicate with other widgets around them i.e. local communication
Embrace complexity in your UI projects – it will only get more complex for you as your users demand richer interactions.


Posted in front end architecture, thinking out loud, web apps | Leave a comment

Enter iPad 2: @naelshawwa’s top 5 iPad apps

For my birthday my fiancé gave me an iPad 2 which I have been talking to her about since the first iPad. My birthday weekend was spent playing with a handful of apps I couldn’t get on my iPhone and or witness familiar apps in all their glory on the iPad.

Here goes, at #5 we have:

#5 Penultimate

I saw my buddy Andrew use this on his iPad, so I got it to try it out. It’s good, not great for writing because its missing this close-up mode, but its free.

#4 Prezi Viewer

This is a sick app! The whole Prezi idea rocked my brain when I first came about it. This app lets you present your Prezis (not create them) anywhere. Great app and its even more amazing when you present it your TV. Next time you’re putting together a deck in Powerpoint or even Keynote – have a look at Prezi first.

#3 iMockups

Brought to you by the guys at Toronto’s Endloop Studios this is a beautiful app for mocking up iOS and web apps. Beautiful designed for designing on the go although I’m not a designer by trade this app will help me visualize what I want to build to others and myself. Job well done boys!

#2 Notes Plus

A great note taking application – works well with your finger or even a stylus. My favourite feature is the close-up writing which makes it easier to take notes and end up with legible notes. Close-up writing makes you write in this “box” in big clear font which then gets positioned on the paper at a smaller size. Other features include a few handy gestures for re-arranging your note and quickly deleting stuff. Beautiful designed app and great for sketches and notes.

#1 Flipboard

Flipboard is absolutely stunning and without doubt it is probably the best designed piece of software I have ever used. Its idea is pretty simple – explore your social networks, blogs, websites, RSS feeds, etc. as a magazine instead. Word’s don’t do it justice, and this video does a better job, but trust me when I say you should try it to really understand.


What are you top 5? Please share in the comments.


Posted in Uncategorized | 1 Comment

Moore’s Law killed HP’s PC business

Last week HP announced that they won’t be making anymore WebOS devices and leaving the PC business altogether. Initially the plan for HP was to integrate WebOS into all their future hardware. That plan is now scrapped. HP seems to be refocusing on their software business which although smaller commands higher margins than the hardware; this post is about why this is a good strategic move.

Negligible margins on sub $1000 PCs

Consider the image above, they’re all different HP laptops from the past decade at least. While yes chips became smaller, stronger, and ultimately cheaper, the laptop itself remained the same. HP like other major PC manufacturers did not control the OS, they focused on the hardware and loaded it with Windows or even Linux. There is hardly any innovation left in the consumer hardware business itself.

Looking at the Laptops & Netbook PCs page on we can see that all their laptop categories start in the sub $1000 price range. Netbooks start at $279, the high performance 17″ model starts at $649 and even comes with a free 6GB memory upgrade. The last most expensive group – dubbed “Envy” – starts at $999.

It is known that the biggest problem for manufacturers with the sub $1000 laptops is Moore’s law and lack of margin. This explains why Apple does not want to participate in that cut throat market. Apple is known for their ability to maintain high margins and even manage to squeeze in more profit per product before expanding their lineups. Even the least expensive Mac i.e. the 11″ MacBook Air has a 28% margin built in, and that is the entry level mode. Upgrade to the 13″ with 128GB MBA and now it’s at 37%.  Supposedly,  a high school student and amateur tech reporter was able to crunch some numbers and show that Apple makes more revenue from the sale of one Mac than HP does from selling SEVEN PCs.

The only consumer-facing innovation left: Design

20 years ago, very few cared about design aesthetics or the overall user experience of tech gadgets and devices. These devices provided enough hardware innovation that there mere existence was great enough. Its the other way today. The hardware is such a small and slowly becoming invisible part of the equation. It is all about how I’m going to use this device, and what I can do with it, and where. Case and point: very few people care what processor is in the iPad vs. a TouchPad vs. a Xoom. 15 years ago we asked is it Pentium IV? or Pentium III? Was it Intel or AMD?, 100Mhz? or 256? Who cares. Only the techies.

As we venture into the age of touch screens, gestures, and augmented reality, hardware innovation will no longer be visible across different devices as they would all becomes boxes with screens that extend to the edges that accept your gestures.

Going forward, similarly with augmented reality applications. Who knows, maybe there will be Surrogates in our life times?


Steve Jobs has a great eye to details, but 30 years ago it was not appreciated and Apple fell behind. The large companies just wanted computers to crunch numbers and store documents. Bill Gates and Microsoft gave them that. Job’s wanted to design and build beautiful computers that did that. When he returned to Apple, he still had the same great attention to detail and the vision he runs with today. It is amazing to see a company go from the verge of bankruptcy to the most valuable company today… in 14 years. His attention to detail is pursued today and that is why Apple hardware commands such high margins. It’s a brand synonmous with high quality, performance, and beauty.

It is not just hardware that is demanding higher design standards, but we are also seeing consumers demand this from software applications regardless of where it is. Soon you’ll even look for a user friendly fridge or stove. It’s about time actually.

Words like “user-friendly”, “intuitive”, “simple” were not too common in the early days of computing. The common answer to all was RTFM.

Lessons from IBM’s 100 year history

IBM’s 100 year history contains a lot of lessons for any company. IBM kept up with the changing times and revised their business model to remain competitive. HP bought Compaq in 2002 for $25B and three years later in 2005  IBM sells the ThinkPad line of PCs to Lenovo. Even though the Compaq deal pushed HP over IBM in 2005 revenue-wise, IBM was able to re-focus its energy into its more profitable software and business consulting lines. Today HP is only re-playing a card IBM did 6 years ago, and IBM is once again ahead.

HP’s Future

I think it’s looking good for HP, things will get worse before getting better but they have clearly admitted what they were doing will not last much longer and they need a change in direction, a U-turn. That’s what they did. HP is big enough to do that today and still survive. They attempted to plug their deficiencies in the consumer devices market by buying Palm but that didn’t work. That investment is still good as it comes with a load of high profile and pursued patents in the mobile. Those will become lucrative.

HP’s offer to buy Autonomy also shows this new direction. The consumer devices field is useless without data, a lot of data. Innovation in UI experiences requires a lot of data. Data needs to be managed. This purchase puts HP facing off with Google over enterprise data management. HP’s model which would be similar to IBM’s than Google’s would probably be more welcomed in the enterprise than Google’s cloud solutions would. Don’t forget it was Google’s mission for the last decade to organize the world’s information and HP recognizes that a lot of the world’s information is locked away behind enterprise firewalls – they too need data management.

Posted in Uncategorized | Leave a comment

The good, the bad, and the ugly: large scale JavaScript apps

It’s pretty sad that no matter how hard JavaScript tries to be more “serious” it is still perceived as that “scripting” language. Compared to Java or C++ or something else that is “more serious” JavaScript won’t have a chance. But why? really it came a long way from where it started.

The saddest part of the story is that it’s called “JavaScript”. The “Java” part was probably just a marketing tactic by Netscape. The “script” part gave it that perception of being “not serious”. So what changed for JavaScript over the last 10 or so years? He-ll-o AJAX.

AJAX is JavaScript’s sexier cousin from some exotic island. Believe it or not, AJAX came to JavaScript first from Microsoft in IE 5. It wasn’t even called AJAX then, it was just XMLHTTP – of course you can’t depend on Microsoft to come up with a better name. AJAX officially got its name in 2005  thanks to Jesse James Garret. AJAX changed everything for JavaScript. More people started talking about it. Customer’s wanted more of it. Everybody was all over AJAX — except those technology guys that thought JavaScript was not “serious” enough.

Even though AJAX and JavaScript have been seen together across the inter webs since the early 2000s it wasn’t really that common until I would say GMail (2004) and Google Maps (2005) came out. Then of course we had Twitter, Facebook and many popular applications build their experience around AJAX. Then we had executives asking for “Web 2.0″, “Ajaxy”, “Googley” applications across giant enterprises that are mainly Microsoft or Java shops that didn’t care about that “hack” JavaScript. (I would argue JavaScript is more appreciated in the Python / PHP / RoR world but that’s just me)

Anyway so what happens next? Well, it is called “JavaScript”, and we have been coding JavaScript for 10 or so years, how bad it can be? This is what a lot of people missed. Today you are building large JavaScript applications unlike what you were doing 10 years ago. 10 years ago you code some JavaScript to perform some client-side validation. Building large applications requires architecture and engineering, not just coding. Yes, and you’re better off with a framework too. However a framework will not save you by itself.

So now we have dozens of JavaScript frameworks and libraries and tools to use, just like the other “more serious” languages we also have MVC, messaging, pub sub, and even build and dependency management systems. JavaScript even has optimization and profiling tools! An automated test harness too! Wow so much has changed since you started using alert().

Where do we go from here? Step number one would be to forget all the bad habits you have picked up since 1995 and start learning some new and better practices. I’ll start you off with  “5 tips to writing better JavaScript” I presented at DevTO last week:

  1. Use namespaces and break code into modules. Modules, modules, modules. Not functions, functions, functions.
  2. Use Event driven programming. Web apps will always be event driven. You’re either responding to a user event or a system event. Architect and program your components as such.
  3. Use a publish/subscribe plugin or something within your framework if it supports it already. Ties nicely into the event driven architecture.
  4. Use a templating engine. Don’t mix HTML markup within JavaScript code or vice versa.
  5. Last but definitely my favourite. Everything is a module. Use decorators to change behaviour dynamically. You can mix and match different JS objects and functions dynamically on demand. This can be very powerful. It’s like your on demand movie subscription…but much better. Imagine you can mix Dexter with True Blood and in the Mad Men days? Wow.

Don’t blame JavaScript for your crappy application. Blame yourself for not taking the time to understand it better. Here’s a good book to start understanding it better: JavaScript: The Good Parts by Douglas Crockford



Also come out to #DevTO which will always be the last Monday of every month to share some more good parts about JavaScript with myself and others :)


Posted in #devTO, dojo, how to, thinking out loud, web apps | 7 Comments

They’re all doing it wrong: tablet ads

Take a look at these tablet commercials, can you spot the similarities?

Toshiba Thrive

Motorolla Xoom

Blackberry Playbook

The first three mentioned things like “flash-loving” or “app-rocking” or how many “ports” it has, or how many “mega pixels” the camera has etc. etc. It doesn’t really matter I think, these specs don’t mean anything to non-techies. Tell me what I can do with it, don’t try to blow my mind with fancy galactic graphics -unless its an app on your tablet. Don’t tell me it’s “flash-loving”. I don’t even know what Flash is. I don’t know that it powers video online, I just know that video can play in my browser. HDMI connection? WTF is that? Show me projecting the tablet’s display onto a 50″ screen instead. 16:10 High Res display? what is this? 2nd year statistics? “3G upgradeable to 4G”? “Dual core processor” As for the Playbook commercial, what are you trying to sell me here? an awesome looking bus stop? or an equally awesome giant touch board room table?

Leave these boring technical details out of your commercials. I won’t buy a tablet because it loves Flash 10.1, nor would I buy one because it has an HDMI port. I won’t buy it because it comes in 12 different colours. Nor would I buy it because it has a 5MP display.

Toshiba, Motorola, RIM: If you still haven’t learned a thing or two about iPhone ads, or iPad ads, here’s a few of my personal favourites. Take notes and remember the three videos above. The products may be good – the Xoom was pretty decent actually – but the commercials sucked.

And now the royal flush of tablets: Apple’s iPad

Posted in Apple, thinking out loud | Leave a comment

Scripting vs. Coding vs. Programming

@laurenonizzle tweeted a link to a forum discussion about the differences between scripting, coding and programming. I’m offering my thoughts here, feel free to chime in with yours.

As indicated by several posters on that forum, the line can get blurry. This is mostly because the terms are used interchangeably. I can be a scripter, coder and programmer at the same time. The definitions can also depend on your development background.


Traditionally, scripting may have referred to “incomplete” or “limited” languages. Usually used as the “glue” that tied different applications together, or just as an easy language to write something quick and dirty to automate some mundane task. Most common examples given are JavaScript, ActionScript and Shell script.

Yes, maybe 10 years ago JavaScript may have been considered a “limited” language – back when it was really mostly used to do some quick form validation or scroll some text on your browser, however that is no longer true today. This misunderstanding of JavaScript today is mostly accredited to developers that don’t understand it or have only used it to scroll text across a screen – and because it ends in “script”. Turn off JavaScript in your browser and try GMail, Facebook or even Google+. This is no longer an “incomplete” or “limited” language – in fact your web application would look incomplete without it; 1995 incomplete. Building a JavaScript based application today requires the same thinking and design you would give while building an application in C or Java. You need to apply the same design patterns that apply on the back-end. Speaking of the back-end, today you can even run JavaScript on the server side. So I can technically write a full GMail clone in just JavaScript.

Similarly with ActionScript. It started out as a “scripting” language to script Flash animations, games and applications. I actually messed around with Flash and ActionScript about 10-12 years ago. It worked different then and was built around that frame by frame concept to build a game or movie. Today, ActionScript 3.0 is actually not a scripting language anymore. It is as complete as a language can be. It is even compiled and runs on the ActionScript virtual machine – exactly like how Java code is compiled and runs on the Java virtual machine. In my mind, it is no less of a language than Java is. Anyway, ActionScript is no longer a scripting language. If you still think ActionScript is an “incomplete” or “limited” language then please check out the Showcase - after that please wipe your brain matter off the screen so you can continue reading the rest of this post.

Another incorrect definition for “scripting” is that it is  to write instructions for another program to parse, but that is what code is anyway. They’re instructions for something else to run. (See #4 in the forum) So what about SQL scripts to query databases? This is a scripting language as well that directs another program ex. MySQL or Oracle how to query your data. But we don’t refer to these people as Oracle Scripters? You’re a SQL programmer. And no SQL programmer would say I’m scripting the query that will get the intersection of X and Y and then join that with the B.

So what is Scripting? I think it is when you use a tool or combination of tools to automate a task or series of tasks – regardless of the language it is written in. I can be lazy, I would script cooking breakfast if I could. It doesn’t have to be just limited to a command line tool. Use what you see most fit for what you are trying to automate. Sometimes I use shell script, sometimes it is an Excel script,  it can be PHP, it can be Java, it can even be C. Whatever.


On to coding. I don’t like this term personally, but sometimes I am a coder too – it’s part of the job – When I’m a coder I’m like this guy:

So a coder is someone who codes from one language to another. It can be from English to Morse code, or from English to Java code. When you are coding, you are translating requirements into a language the environment your application will run in will eventually understand (server, PC, iPhone, browser, etc.), and this is where the term “code monkey” comes in and why I dislike the term coding. Sometimes you got to do what you got to do and just crank out code.


To program any machine or application requires you provide it with a set of instructions to run. Be it your fancy coffee machine that is programmed to have coffee ready by 7:15am. It can be the radio in your car i.e. you program your favourite channels into it. Or it can be set of instructions telling your browser how bounce a ball GIF around on the page.

So what does this all mean? It means they’re all the same – sorry there is no big bang explanation here. At the end whether you are scripting, coding or programming, you are providing some environment like a PC, robot, or browser, a set of instructions on what tasks it needs to perform. Whether the language you do this is high level or low level has nothing to do with it. Whether it ends in “script” or ends in “++” has nothing to do with it. Whether it runs on your browser or on a mainframe has nothing to do with it. Whether it is intended to be sold to millions or just used by you has nothing to do with it.

I’d suggest you use none of the above terms. You’re a software craftsman. You design and build solutions using the best suited technologies for the problem you are trying to solve.

Posted in thinking out loud | 4 Comments

#DevTO – You don’t just write code

#DevTO started out with @kevinkvs and @jonezy thinking about the need to have a regular meet up for developers in Toronto to share and learn from each other. I first heard of this idea on Twitter from Chris and was immediately intrigued and offered to help out. @clickflickca also joined in later on the fun and brings his experience organizing and running other events around Toronto.

A big part of our jobs involves learning; from yourself and others around you. The challenges you encounter are as wide as the job titles. The other big part of the job, is showing off how you solved that problem and what you have learned.

Some of us are lucky to have a team of awesome developers that you work with every day to learn from, bounce ideas off and show off the end result. Some of us might not have that daily. How to convince your boss that the database needs optimization? How can you reduce your build time in half? Need to know about common pitfalls building mobile sites? Got some IE6 horror stories and the scars to prove them? This is where #DevTO comes in.

No matter what technologies you have used, are currently using or are thinking of learning #DevTO is for you. The broader the audience the better. This event is not just limited to developers. Kevin co-founder and Community Cobra Commander of #DevTO said it best:

If you are liking the sound of this so far then make sure you RSVP to our second event tomorrow night:

Posted in #devTO | 1 Comment

All developers are not created equal – hence not interchangeable

Earlier yesterday I came across this article on the New York Times: Thieves Found Citigroup Site an Easy Entry. At first I thought, “Man, another big site had their customer data compromised”, but as I continued reading this incident is a little bit different; especially the nature of the attack that was described in the article. The marketing and PR departments for these brands – and in this case Citigroup – need to be a little more careful about the kind of technical information that gets released when shit hits the fan.

Think of it as a mansion with a high-tech security system — but the front door wasn’t locked tight.

After reading through the article and the retarded nature of the attack you can’t think of it as a mansion with a high tech security system; not even close. Some context on this attack:

In the Citi breach, the data thieves were able to penetrate the bank’s defenses by first logging on to the site reserved for its credit card customers.Once inside, they leapfrogged between the accounts of different Citi customers by inserting vari-ous account numbers into a string of text located in the browser’s address bar. The hackers’ code systems automatically repeated this exercise tens of thousands of times — allowing them to capture the confidential private data.The method is seemingly simple, but the fact that the thieves knew to focus on this particular vulnerability marks the Citigroup attack as especially ingenious, security experts said.

So, all these thieves needed to do is basically log in with their own or even someone else’s Citigroup account and lo and behold this account number was present in the address bar after login. Changing it gave them access to someone else’s account. A little script to repeat this for thousands of accounts and scrape the details.

This process was described by “security experts” as “especially ingenious”. Really?!? This is the oldest trick in the book; i.e. mess around with the URL until you get somewhere. These “security experts” should get fired if this kind of attack was surprising.

The “what can we do, we got hacked” wagon got extremely popular in recent years, especially this year, but this Citigroup incident is different. There is no excuse for being on the “we are retards, we got hacked” wagon. When your “high-tech security system” is composed of changing account numbers in URLs, then what else can someone find if they look harder?

How does one get to this position? I think at the root of the problem is the thinking that people working in technology are interchangeable cogs in a giant machine. When you are building the pyramids, yes you can get 40,000 slaves and have them drag giant slabs of rock into place and stack them with virtually no way for an error to occur. And yes you can get another 40,000 slaves and replace the first 40,000 and they will still drag and stack the rocks as good as the previous 40,000 did. That mentality works when the tasks at hand are fairly simple and mechanical such as building the pyramids, or the production line at Ford. It is absolutely not valid in technology, yet there are many executives, project managers, and software architects today that think its possible.

The other part of the problem has to do with measuring expertise. The above assumption that developers, architects, designers, etc. are interchangeable also leads to the flawed assumption that a developer with 10 years of experience can replace any other developer with 10 years of experience as well. It is easy to get to that assumption when you think of these tasks as mechanical such as building the pyramids, or putting the wheels on a car. 10 years of experience developing doesn’t have the same weight it did 30 years ago. Most developers today got into while they are teenagers, and hence by the time they graduate university they already have 10 years of experience developing stuff. Also, there are more technologies today that are available to the average developer to experiment with and try out, than there was 30 years ago. Hence why building technology systems  and development in general is a combination of science and art. The Sistine Chapel would have looked different if Leonardo da Vinci painted it instead even if he got the same directions from the Pope. The Pyramids would have looked the same regardless where the 40,000 slaves came from.

So for an online application that has to do with people’s credit card accounts to fail at this level doesn’t give me the warm fuzzy feeling that I should be getting when I read “Citi has implemented enhanced procedures to prevent a recurrence of this type of event.” – if I were a customer.

Where else did you not do the due diligence you owe your customers? What other skeletons are in the closet? The New York Article should have started out like this:

Think of it as a tent with a zipper — but the zipper wasn’t closed.

Posted in Software, thinking out loud, web apps | Leave a comment