Archives for category: rants

I love the color pink/purple - I change my syntax highlighting colors so that I comment more...

One day, a software developer was walking down the street and came across a large pill of dog shit.  He bent down to get a closer look and said to himself “yep, that looks like shit”.  He then gave it a sniff, and said “Yep, that smells like shit”.  He then put his finger in it, and said “Yep, this feels like shit”.  Finally he did the unthinkable and tasted his finger and happily said: “Oh yeah, that tastes like shit…”.  He then walked away satisfied, and said out loud:

“That was definitely dog shit.  Good thing I didn’t step in it!”

An old joke which I managed to re-arrange and fit into my experiences with software.  Sometimes you have to taste the shit to avoid stepping in it. Don’t look too deeply into the metaphor.  Testing is hard, not everyone wants to do it, but it is your duty to prepare for and handle the worst, so your customers don’t need to.  I guess there is a hidden message about thoroughness too.

Part2 of my follow up from Cusec2010, regards Douglas Crockford’s talk on “The Software Crisis”.

Short version for those headline skimmers:  Crockford says that the Software industry is in a state of crisis, we need to fix it and we must fix it.  I agree with all his recommendations and examples of flaws in our industry, but I argue that it isn’t  necessarily a flaw but an inherent relationship between the software industry and the business world.  Buggy software is often good enough, so lets just try to make it a bit better.

As a precursor to this talk, for the last few months I have been thinking about a similar (if not the same) problem: The software crisis. I had been talking with friends about something that bothered me about the software industry, imperfect code, imperfect process, the imperfect software industry.  When Crockford stepped on stage and showed his first slide “The Software Crisis”, without him even continuing, I knew exactly what he meant.  First off “Thank you Douglas for putting a name to an issue for me”, it was like remembering the lyrics to a song for a week without being able to remember who sings it.   His talk was on aspects of the crisis, why they exist and how we can minimize and pave a brighter future.  He had my attention….

I won’t go into the dirty details of the crisis itself (a quick google search should help you with that), but in short: we are getting lazy, we are producing bad production code, we are delivering late, we are testing too late, we are in major trouble.  Why does this happen, and what can we do?  Crockford opened by stating that creating software is the most complex task a human being can do. (Paraphrased, someone please msg me if you can remember the exact quote)

Read the rest of this entry »

Why are things always so obvious after disaster happens, I think they call that hindsight

One of the final talks I attended at CUSEC 2010 in Montreal, was probably the most important, and unfortunately – (seemingly) the most underrated. Daniel Berry from University of Waterloo Software Engineering gave a talk entitled “Ambiguous Natural Language in Requirements Engineering”. Unfortunately he was speaking to an audience in the Agile area who have been exposed to culture stating that Waterfall Software Process is dead. More inaccurately, that requirements gathering is a dead science. This talk was not only enlightening, but also made me rethink many topics I haven’t thought about since University.

In summary for those who don’t want the verbose version: The process of transforming the ‘idea’ (as a requirement) and turning it into ‘code’ is a problem that extends well beyond just the ‘code’ part. Many software errors (%5-%10) are a result of ambiguous requirements – Requirements that neither party in the process even knew were ambiguous. This talk was a branch of Software Engineering shining at its best – and Berry offered solutions!

First to address those developers still pretending this problem doesn’t apply to them: Not all software projects involve 1-2 developers. Not all projects allow you (the developer) to talk directly to a client. Some projects will have you writing code based on requirements written by someone else in your company. This problem exists whether you want to believe it or not.

Read the rest of this entry »

This post will probably make people think I am insane for bring up such a small issue.  But little things bother me, and this little thing has bothered me for years, and I have been waiting for Microsoft to fix this.  No matter what email client you choose to use, there is a set of basic features that all must support.  Once you start looking at competitve advantages, little features make the difference.

Target for today’s discussion: Windows Live! Hotmail

As a synopsis (to those who don’t want to read the whole post): Unlike all of its major competitors, Hotmail does not allow users to mark emails as unread within the context of reading an email.  As a secondary, they provide buttons that don’t actually do anything.

I will also look at some competitors: Gmail, Yahoo! Mail, and Facebook’s Message Inbox

The left navigation area of 4 popular message/email clients

I use a lot of email clients, gmail/hotmail mainly.  I also use 2 other lesser known clients but mostly to keep up on innovations in the UI etc.  Over the years, (after gmail came out) Yahoo! Mail seemed to be the only client that made improvements or drastic changes to their interface.

I took this above screenshot because it demonstrates how I (and many others) use email.  I generally try to keep my email box with 0 unread emails.  As it gets closer to Friday my work inbox sometimes gets up to 10, but I am pretty good keeping it low.  When I read a message and realize it is too long to read at the current moment, I mark it as unread.  Similarly, if there is an important email, with vital information I will need in the near future, I will mark it as unread.  Some clients allow the ability to mark or flag as important/follow up.  Most clients allow folders for organization.  Depending on the user’s level of organization they may have their own way of dealing with such messages.  Personally, I like to mark anything as “unread” until I have fully closed off all ties with that particular issue.  It is the one thing that at the end of the day, reminds me there is something outstanding (The big number beside my inbox).

Read the rest of this entry »