Juixe Techknow

Rasmus Lerdorf, the Danish creator of the PHP programming language, recently tweeted the following bit of hubris.

For all the folks getting excited about my quotes. Here is another – Yes, I am a terrible coder, but I am probably still better than you :)

That sounds like something that DHH would say, who also happens to be a Danish programmer. In one hand he did invent a new programming language, in the other it was PHP. In one hand he made web programming accessible to thousands of developer, in the other hand the code produced by most of these developers is unreadable and unmanageable.

Of course, a great many folks took the troll bait and commented on the validity of the tweet. My favorite comment was from
Entropy on Reddit.

Kenny G plays the saxophone better than I do, but that provides little solace for his countless victims.

I was not able to find additional background to this tweet, but I can only imagine he tweeted it in good fun, and not in my milkshake brings all the developers to the yard, and their like, it’s better than yours.

Software users didn’t take Knuth in college and you should not expect them to have a Computer Science degree to understand how to use your application. There is no worse assumption that a software programmer can make than to assume that end users know what you are talking about, especially when there is so much miscommunication involved in specifying, designing, implementing, testing, and releasing a software application within an internal team. Your users don’t understand your language, they don’t understand what you mean when you say object-oriented, exception handling, concatenated document, application server log file, null pointer, database query and they don’t care so don’t use these expressions in labels or descriptions in your UI! If you have to explain your User Interface to a end user, your are doing usability wrong. Forget leaky abstraction, there is nothing worse than leaky implementation details in your UI. If your users have to use suspended disbelief and take your word for it to understand how your User Interface works, you should go back to the drawing board.

One of the reasons why the User Interface and User Experience is so horrible in applications, especially internal and enterprise applications, is that they are done by programmers, usually prototyped quickly, and shipped soon thereafter. The truth is that programmers have to wear multiple hats, depending of your company size, these included tester, computer programmer, domain expert, UI designer, type editor, IT, security guru, database administrator, system architect, document writer, and more. In addition of having to fill all of these roles, there usually must be done in a tight deadline with many technology risks, unknown factors untested partners, and already late dependencies.

The simple fact is that the more hats a programmer wears the less productive he will be. If you have programmer having to manage your version control system, update your application UI, and debug memory you are not getting your monies worth. The more hats you have developers wear, the more time it will take to context switch, the more time you spend tracking down issues, and the more you pay in the end.

A use case is just one corner case, and developers working with code very often test just for that one corner case. A corner case can be described as a program error or software bug that occurs outside of normal use, or caused by parameter values and environments outside the intended acceptable range. I’ve learned that corner cases are more common than what developers like to admit, so much so that working code is just another corner case.

In my experience, the number one source of corner cases are assumptions hard code and baked into the source code, like assuming that your users have five digit zip codes, or use an English alphabet, or are based in a specific timezone, etc. Sometimes corner cases arise because someone cut a corner, didn’t check if an input parameter fit a certain criteria, was of a specific format, length, or within an acceptable range. Yet with all the assumptions we inadvertently leave behind in our code, I’ve seen developers take great offense and defend their code with the fervor of a religious zealot by saying, “you are not supposed to enter non-numeric values.” Even with the most stringent process and under tight deadlines, developers have been known to regress to the “if it compiles, ship it” mentality. You can cut corners in the design and implementation of a software program, but you most often will not cut the corner cases where bugs like to linger, hide, and build nests out of code. The number of corner cases is proportional to the complexity of an application.

From time to time I just blast tweets about software development, project planning, team dynamics, or whatever else comes to mind. Here is a synopsis of recent tweets and rants. If you want to follow the conversation follow me at techknow and/or juixe and I’ll be sure to follow back.

Software Development

• Security pet peeves: captchas, security questions, having to login after changing my password.
• A supercomputer won’t solve the incompetence of bad programmers on a deadline.
• All software is in beta.
• The Like button needs to be killed.
• \-: “premature optimization is root all of evil.” (-: “That’s what she said.”
• This must be a record. I just improved our app’s memory consumption by 80%, some 400MB, by changing one line of code.
• I love technology because I can now blame my misspelling on my iPhone.
• Where 2.0 is the new meme. Is your website Where 2.0 aware?
• Building a community and building a business around a community are not the same thing.
• The linked list was recently patented, I’m going to patent something critical to civilization, like calculus or pottery.
• Dear debugger, I wish you could introspect my feelings and put a breakpoint on my heart break.
• A slew of computer bugs are caused by assumptions made by the programmer.
• You know things are bad when you get error code 0000.
• Bugs grow organically.
• It is possible to make spaghetti code out of Obeject Oriented Programmmmmming?
• Rule of thumb: use immutable objects as keys to hash maps otherwise get to you your debugger.

Team Leadership

• The best ideas are free.
• No matter what, you will never be less busy.
• Let’s be honest, anywhere from 10-30% of a resume is a stretch.
• So as not to forget anything, remember nothing.
• When you give someone else time, you waste you own.
• Don’t give any answer, give the right question.
• If you have a one trick pony, ride it until it is ready to be put to pasture.
• Problems are meant to be solved only if they can’t be ignored.
• The one best possible thing you can do to make any situation better is to not make it worse.
• One can lead by asking questions, just as well as giving orders.
• If you build it, they will come. But if you make it to complex or change it to often, then they will leave.
• The secret ingredient is to believe there is a secret ingredient.
• I don’t express myself best when speaking, but when reflecting.
• Praying may not change the world, but it can change your perspective which is helpful to change your world.
• Folks usually want the what first but I think that the why and the how is more important than the what.

Product Placement

• Facebook announced a major investment by the CIA. It was reported that the US Gov will push for Facebook Connect as a National ID program.
• PayPal just sucks. I can transfer money to former Soviet Bloc countries faster than I can between PayPal and my bank.
• Spam is like a staple in Hawaii. So it comes as no surprise that Mahalo is one of the most spam ridden sites online.
• My suggestion to cable companies: give away basic cable to every American with on demand features. Add value outside the cable box.
• Which will provide better value/info for businesses, yelp or foursquare?
• The current Apple Appstore approval time is rand() * Months.
• McDs should make a tofu McMuffin.
• A sign at a Palo Alto church: redeem your soul, there is an app for that.
• Purple Cow Thinking: don’t be boring, safe is risky, design rules now, very good is bad.

Quote

• If there is a limit, you should, you must test it. – Seth Godin/Purple Cow
• Vision without execution is hallucination – Thomas Edison
• Success is not the key to happiness. Happiness is the key to success. If you love what you are doing, you will be successful. – Herman Cain

The iPad has garnered the most press I have seen for a electronic device since, well, the iPhone. Just after a day after it’s release, it has already been jail broken. Here is a list of my favorite iPad reviews, resources, articles with tips and tricks, etc. I hope you are reading this in your new iPad!!!

• The iPad Gets Jailbreaked In Less Then A Day
• Nicholas Carr’s Blog: The post-book book
• Apple iPad Review
• iPad Verdict After One Day
• iPad is to iPhone as…
• iPad Teardown
• Official Gmail Blog: Gmail on the iPad
• The iPad needs its HyperCard
• Landing Pad — an iPad Design Gallery
• How to Make Money on the iPad
• Netflix Streaming App Coming to iPad
• iPad Arcade Cabinet
• 10 Ways the Apple iPad Will Change Our Lives
• Check if Someone Hacked Your GMail Account
• Best iPad Review Ever
• So, iPad
• Summary of iPad Review

I’ve always been interested in understanding common programming errors so that I can easily recognize and diagnose problems, hopefully without spending hours staring at my breakpoints in my debugger. Previously, I’ve written on Common Groovy Errors and Top Worse Java Errors.

The US Department of Homeland Security, under the Common Weakness Enumeration initiative put out the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors. Most of the errors noted related to web application security programming errors.

• Failure to Preserve Web Page Structure (‘Cross-site Scripting’)
• Improper Sanitization of Special Elements used in an SQL Command (‘SQL Injection’)
• Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)
• Cross-Site Request Forgery (CSRF)
• Improper Access Control (Authorization)
• Reliance on Untrusted Inputs in a Security Decision
• Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)
• Unrestricted Upload of File with Dangerous Type
• Improper Sanitization of Special Elements used in an OS Command (‘OS Command Injection’)
• Missing Encryption of Sensitive Data
• Use of Hard-coded Credentials
• Buffer Access with Incorrect Length Value
• Improper Control of Filename for Include/Require Statement in PHP Program (‘PHP File Inclusion’)
• Improper Validation of Array Index
• Improper Check for Unusual or Exceptional Conditions
• Information Exposure Through an Error Message
• Integer Overflow or Wraparound
• Incorrect Calculation of Buffer Size
• Missing Authentication for Critical Function
• Download of Code Without Integrity Check
• Incorrect Permission Assignment for Critical Resource
• Allocation of Resources Without Limits or Throttling
• URL Redirection to Untrusted Site (‘Open Redirect’)
• Use of a Broken or Risky Cryptographic Algorithm
• Race Condition