We all have heard of missiles blowing up in midair because of the wrong unit was used in calculating the trajectory or bank software that misplaced millions of dollars because of a decimal place. It might not compare against blowing up a multi-million dollar missile but here are some of the worst software bugs I’ve seen in projects where I’ve worked.
Shift + O Short Cut – I once worked on a software application where one of the engineers developed a screen search functionality that would find the UI screen by name or feature. Needless to say the modal pop-up dialog for this search feature popped up when the user hit the Shift + O keys. This feature was developed by the engineer on his own initiative, so you can imagine everyone’s surprised when we couldn’t even type a capital o without this thing popping up.
Exposing Regular Expressions – In another project we developed micro expression language which was used and exposed at the application level to users. In one situation, a user reported a error when he wanted to replace a variable place holder with a dollar amount. It seems that when he called the expression language replaceall(“AMOUNT_VALUE”, “$0.00”) the got back the value of AMOUNT_VALUE.00. This problem was caused because we used Java Regular Expressions feature of the String class and $0 expression is a special value in the Java RegEx. This was like a Regular Expression Injection bug.
Localization and Internationalization – In the same project we had a problem with displaying the correct currency symbol used in a financial account statement. There is a big difference between $100 and €100. Account holders are not happy to know that their €100 are now worth $100.
Cut/Copy/Paste Does Not Work – I have seen way too many Java/Swing application where some component does not have proper support for cut, copy, or paste. When you cut from a Java application and paste to say Notepad you get a stringified Java object.
Textarea Size Limit – When filling online forms, the one bug that just kills me is where a textarea has a size limit not shown and you spend time typing a long response which will be either truncated, lost, or rejected on submit.
I don’t count my progress by the line of codes but at the same time I don’t take pride by over engineering a solution. Writing code is like writing for a publication, you have to know at what reading level you are writing for. That said, the one type of code statement that gets under my skin is what I call the run-on code statement. A Run-on code statement is one that has multiple method calls in one statement. Here is a made up example of a run-on code statement.
In the above run-on code statement there are four method calls. I’ve seen worse. The reason whey run-on code statements are a pet peeve or mine is that if anyone method call fails because of a NullPointerException or some other error it’s difficult to quickly know what segment of the code statement failed. This is also annoying to debug if you want to step into one method out of the four.
Here is a short clip of Steve Jobs introducing the new Think Different ad campaign which includes the Here’s To The Crazy Ones speech. From this clip, here are my favorite quotes from Steve Jobs.
The Apple brand has clearly suffered from neglect in this area in the last few years and we need to bring it back. The way to do that is not to talk about speeds and feeds; not to talk about mips and megahertz; not to talk about why we’re better than Windows…
Our customers want to know who is Apple and what is it that we stand for, where do we fit in this world. What we are about isn’t making boxes to get people to get their jobs done, although we do that well, we do that better than almost anybody in some cases. But Apple is about something more than that. Apple at the core, it’s core value, is that we believe that people with passion can change the world for the better.
It is easy to be amazed by the accomplishments of Steve Jobs, from starting the personal computing industry, to revolutionizing the music industry, to leading the way on the mobile front. What amazes me everyday is what his innovation has meant to people. How many moments where shared, songs created, emails read, videos edited, photos fixed, homework done, thesis papers written, video calls made, art projects submitted, lives touched because of his work. There is people with disabilities that use the devices he designed, children with autism are learning on iTouch devices, freelance designers and developers are making a career on his platform, industries have been created around his vision. 313 patents is impressive but the number of ways his genius has benefited us all is innumerable.
Processes are supposed to support people, not people support processes. A process should be documented in one document or checklist or directory or wiki or website that everyone has access to. Everyone should have a copy readily available. It should not be outlined in emails or sporadically over several documents across different locations. Always review the process and remove friction. Try to minimize steps when possible, centralize the information, anoint clear responsibilities, build in safety nets, empower developer to make decisions, let it grow as the team grows. Automate the process as much as you can, make reports people can use, make everyone’s progress visible. For some certain teams, there is diminishing returns for adding more processes.
Even when I have been the sole developer in a class, interface, module, library, or feature I try to always report progress as “We.” For defects and issues it’s always easy to point out the fault and personalize the problem when it was caused by someone else. Avoid naming names or singling out an individual. Saying “Your broke this” doesn’t make you look better or solve the issue. Restate it as “This was broken by this change list you committed on this date while trying to resolve this other issue.” Don’t personalize blame or fault, and provide as much information as you can gather to better solve the issue. Don’t stop when you find something is broken, or when you find who broke it, find out why it was broken in the first place, and if at all possible suggest viable solutions.
A few days ago, a engineer called me over for some help. He immediately started making using accusatory language as if I had committed some crime. “There is a bug and you wrote this so you did it and you didn’t do it well because there is a bug.” He was pointing to 20 lines of code that I had written over a year ago in a much larger feature whose requirements had changed over time and because of his tone and desperation in his voice I could tell he was lost just dropped the anchor of blame wherever he could. I tried to get focus to the task at hand an not my code and asked a series of questions, what does the system do now? What should the system do? Does this always happen? What is unique when there is an error? Using this approach we found the issue in 10 minutes without staring down the code or focusing who wrote what method.