Insomnia

Yesterday, after an interesting debugging session, I was able to fix a long standing issue that was quite tricky to find. This problem had been plaguing the system ever since we inherited it from the customer. The problem shouldn't have been so difficult to find as it is really obvious when you understand what happened.

The reason why it eluded us for so long is that the root cause (database deadlock) was hidden behind layers of abstraction (ORM) that did not do a good enough job of abstracting the physical characteristics of the system.

Although the fix was simple, the root cause was tricky. To make matters worse, that pattern that caused the problem is used everywhere throughout the application. So this morning, I spent 30 minutes to write up an email explaining the pattern and the problems with it. The email also spoke of a way to fix the broken pattern. Sent it to everyone in the team.

To my surprise, the payout was immediate. Before the day was over, I had a patch to review. A problem with a customer notification email not going out. And lo and behold, the cause was a database deadlock. And the fix was to modify the pattern the way that was outlined in my email.

The lesson here is that knowledge is valuable, but it is much more valuable when it is shared.

Labels: work

• 1 Comments

This evening, after dinner, I went for a latte at Starbucks. I was enjoying the beverage listening to the standard coffee house music. Tracy Chapman if I remember although my odds are pretty good with that guess considering the location.

Then I did something I rarely do. I read the little thought on the cup.

Failure's hard, but success is far more dangerous. If you're successful at the wrong thing, the mix of praise and money and opportunity can lock you in forever.

-Po Bronson, Author

I kept the cup. Even took a picture to remember.

And then I started to ask myself if I was successful at the wrong thing?

Labels: work

• 3 Comments

Jeff Atwood had a really quotable sentence in his latest blog post: Coding Horror: Real Ultimate Programming Power

"Throwing a book of rules at a terrible programmer just creates a terrible programmer with a bruise on their head where the book bounced off."

This funny sentence expresses something that I have had a really hard time expressing for the past few years: Rules and processes don't make your terrible programmers better, it limits the damage that they can cause to your project.

Not all problems can be solved by adding process.

The only long term solution to dealing with terrible programmers is to give them the tools to become good programmers. Training, mentoring and support. And the training shouldn't be about process but about the craft of programming. Reading code, using a debugger, how to solve a problem with software.

Labels: work

• 5 Comments

This morning, while I was shopping at the store, I was looking for product reviews on my blackberry. Every search I made on Google issued a warning about the site being potentially harmful to my computer. Even sites that I know or run had this issue. This was obviously a mistake on the part of Google. They issued an explanation about this error on their blog.

Basically, it was a manipulation error in the lists they manage of known bad sites. I am sure Google has procedures to ensure this doesn't happen but things like that still happen in spite of best efforts.

We fell victim to something very similar this week. While we were testing an upgrade to the software of one of our customer's web sites, we misconfigured the staging server and sent outdated notifications to a few hundred of their customers. This must have surprised the recipients and surely triggered a few customer service calls that they were not counting on.

What make this story interesting is that we had planned for this and had prepared a procedure for staging that made sure to neuter the notification service. A manipulation error in the server configuration caused all this planning to go to waste. After we had fixed our mistake and notified the customer to expect a few strange calls, we looked at what happened. It was clear that the mistake did not sit with one particular individual but was a failure of our internal communication for this staging procedure.

At least we learned something and we can fix our procedure. But today's Google issue makes me feel a little better about it. Even the biggest web company in the world has its bad days.

Labels: work

• 0 Comments

We are currently redoing the design of the web site at work. Since we didn't want to use stock photography (we wanted to be more authentic), a photographer came to the office yesterday all day and snapped action shots of some of us.

The photographer would set the stage tell us to sit here and there and proceeded to take pictures. At one point, he turned to me and asked if I could go back to my desk and fetch some random papers and other office supplies to lay out on the table that we were using for the picture.

We put that on the table and he said to us with a wry smile: "Now, look passionate and happy and authentic". We all laughed and went on to perform exaggerated pointing gestures and striking phony poses worthy of an 80's Sears catalog.

And then, something interesting happened. François pointed at the random paper that I had brought from my desk and asked what project it was about. And that is all it took. We started a genuine, passionate discussion of this project. I went on to explain the customer's needs and discussed the various technologies that we were looking at. I went on to explain that the project was early in its conception and that it required a lot of investigation for some of the most innovative parts.

Then François and Sylvain started making suggestions and asking more questions and the discussion became quite animated. By that time, we had completely forgotten that the photograph was there. He had to intererupt our discussion to ask us to take a different pose.

I don't know if the pictures will come out good. But I don't think we could have faked a better passionate, happy and authentic than this.

Labels: work

• 0 Comments

So, November 13 is world usability day. I will be at the OCRI event to listen to the discussion and maybe participate. I am looking forward to the panel and to meet new people interested in usability and design.

Labels: design, work

• 0 Comments

I was reading the latest post on Fred's blog. It hit home for me as well. My personal problem is not that I have too many feeds to read (I prune my list regularly) but that I tend to skip anything that has any substance.

And it is only going to get worse. Apparently, blogging is dead, (many people have claimed that on blogs recently... completely missing the irony). Blog posts are too long for today's spastic readers. It's Twitter nation now. If it is more than 150 characters, you just lost most of your audience. "Smart" people don't blog anymore, they twit.

This translates in our everyday life and in our work habits too. Coincidently, I jut got an email from Fred this evening with a document to review. I read the first paragraph and I closed it. Preferring to respond to the stimuli of my Twitterific icon. This is a really bad habit.

Labels: tech, work

• 0 Comments

Reposting this link from the Voltage Blog.

HP Goes Green and It’s More Than Just Marketing BS | Voltage Blog

I'm not usually using a "green" label as a way to distinguish products. Usually... it is just marketing/PR. In this case, it seems like a genuinely original idea.

Proud to call HP one of my customers.

Labels: tech, work

• 1 Comments

Remember my post about Winzip?

They actually called back to check if we did a license audit. I told their representative, in person, that we didn't really do a license audit as they requested. But that, instead of doing an audit, our staff was instructed to uninstall WinZip and use a free alternative like 7-Zip.

She seemed all happy at this conclusion and thanked me for my help. That's it! No sales pitch, no offer to help us with anything. They had me on the phone and didn't even make an attempt to establish any sort of contact. I had assumed that this was the reason for the whole license audit thing in the first place. But no. They truly just wanted people to comply with their licensing terms.

I am a little baffled.

Labels: fun, work

• 1 Comments

Once in a blue moon, I need to demo a feature to a customer or host an application sharing session. Like many people, I had used the trial version of WebEx to do this. Since I don't feel like I do this often enough to subscribe to their service, I had not.

Last week, I needed to do another demo. Remembering the fact that the last time I had used their trial software, they called me for nearly a year to get me to subscribe to their service; I was looking for something else.

This is where I found Microsoft SharedView. If you are doing a demo for a small group (less than 15) and you have another mean of doing the voice conferencing, this should work great for you. I was able to set it up in 5 minutes, I already had a Microsoft LiveID (from MSN Messenger) and I had a sharing session setup in no time.

The system is free, lets you send invites by email and doesn't require the attendees to have a Microsoft LiveID. It worked flawlessly for me even if there were 2 firewalls and a whole lot of routing equipment between me and my customer. I had no special setup to do. Performance was similar to previous webex experiences. The system lets you give control to any attendee and lets the attendes "scribble" on the screen as they talk to point things out.

One thing that seemed different than webex is that you can only share one application at a time. If you want to share more, you have to share your entire desktop. Maybe there is a way around this but I didn't bother trying to figure it out, it is not that big a limitation. Obviously, this is Windows specific so that might be a no-go for you.

Labels: work

• 4 Comments

My company is in the product development outsourcing business. We write software on behalf of other companies. Often, we work with other software companies. This is a hard sell. It requires a lot of versatility from our sales staff. They have to sell a service that they individually have no use for and that they don't fully understand themselves. Sometimes, the discussion with the customer becomes very technical and they need some backup from the technical staff to convince the customer.

That is usually when they call me. They start the discussion, introduce the company and then, they call me to fill in the gap. Once all technical questions have been addressed, they get back into closing mode and make a deal. So, in my naïveté, I thought to myself... How hard can this be?

A couple of weeks ago, I had the opportunity to get my perceptions reset. I went to visit a new prospective customer solo. This was a last minute thing and we couldn't assemble a team fast enough. I had experience with those meetings and I was prepared, I had a presentation ready, sample projects to talk about, I thought that I would just walk in there and close my first deal. The meeting went well. After the meeting, the customer and I were chatting on our way out of the office and he said something to me that just shocked me:

You are a dealbreaker, not a dealmaker.

That's it I thought. I flew all the way out here just to screw it up.

Seeing that I was... perplexed by this statement, he promptly clarified: You are the kind of guy that would walk away and not look back if the deal doesn't make sense to you. You will not try and fix it and close a deal that is not that good.

I blinked, not knowing if this was a good thing or a bad thing. He picked up on that and told me that he was happy that I was a dealbreaker. He said that he wanted to deal with someone that would take ownership of their product and that would not compromise on achieving the objectives. He asked me a few questions and he asked me to work on some pricing to be discussed the next morning. Two weeks later, we're still negotiating and it looks like we're going to work together.

I realize now that I was lucky. I just happened to fall on the one customer that needed to deal with someone like me. I realize that I will have to let dealmakers make deals. And that I should just be happy with my support role. It takes a lot of skill to convince someone to spend tens of thousands of dollars with someone that they have just met. Without the dealmakers, us dealbreakers would be out of a job.

Labels: work

• 1 Comments

Sometimes, ignoring your gut might be the thing that you do that requires the most experience and intuition. I find that this is a rule that often applies when trying to solve a software performance problem.

You see, my current project is a business intelligence and reporting product powered by Microsoft Analysis Services. I have spent a while on this project an I am getting pretty good at understanding what happens under the hood of the engine when the application performs queries. I have also spent a lot of time so far tuning the data cube to allow the application to achieve a good level of performance.

Recently, my customer started using the application with real-world data and was puzzled by the response times he was getting from one of the datasets. It was a rather small dataset with nothing out of the ordinary. One view, no calculations. Something really basic. But every time you performed an operation, you had to wait for an unusual 5-7 second delay before getting responses from the database.

I spent a day working with that dataset, massaging it, creating indexes and aggregations. pushing and prodding every which a way. Applying the same recipes that got me some level of success in the past. But nothing happened. I knew that what I was doing was improving things because I could measure the imrovement on the other datasets but this one remained very sluggish.

So I resigned myself to write to my customer with a hypothesis that I had about the reason why this dataset was slow (lots of "zero" values instead of nulls... that was my hypothesis... really lame in retrospect). As I was writing, I spent the time to explain the things that I had tried and, since my customer is smart but he is not necessarily an MDX query expert, I "took id down a notch" on the technical side. Taking care of going through all the details and all the steps. And as I was explaining, It struck me that I didn't really do all that I was writing. I didn't examine the data to see if it was different, I just quickly glanced and the text files containing the raw data and gauged the complexity of the dataset by their number and their sizes.

So I took a step back and I went back to the basics. I carefully examined all the dimensions of my data cube to realize that I had one dimension with a really large number of members. A 100:1 ratio compared to the other datasets that I had imported in the application before. It was so simple. The total "size" of the imported data files were similar but the "shape" and size of the resulting data cube was radically different. The way the queries were constructed made assumptions that were wrong. After that was identified, it was easy to come-up with a plan and test a few queries to validate my findings. All of this would have taken an hour if I had spend the time to go through all the steps.

Today, my experience and my knowledge was my worst enemy and it led me on a wild goose chase. When I started questioning my assumptions, the answer was staring at me right in the face. And yes... sometimes, you have to check if the computer is still plugged in.

Labels: work

• 0 Comments

Recently Matt was telling me that there was a certain amount of backlash in "The Valley" against working with Indian or Chinese colleagues. Not because they are not competent. But because it required people in California to stay at the office late in the day to be able to attend meetings with their Asian colleagues.

Interestingly, on the east coast, the situation is a little different. We benefit from the willingness of our colleagues in India and Eastern Europe to stay late for meetings (sometimes quite late). In order to be considerate to our colleagues overseas, we scheduled our daily SCRUM meeting early in the morning. By early, I mean 9:30.

Now, what is starting to happen is that our employees are complaining that this meeting does not match the core hours of our flexible time policy. The core hours are described in the employee manual as 10:30 - 15:30.

So begins the clash between HR needs and business needs. We need the help of our overseas colleagues to complete projects because there is not enough local talent to answer the demand. And we need to provide a comfortable, inviting work environment for our employees in all of our offices.

Anyone has smart ideas on how to solve this?

Labels: work

• 3 Comments

I was reading this article about the shocking steps that General Motors was taking to bootstrap their electric car project (called Volt). To allow themselves to innovate, they brought back a senior engineer from Germany and they threw all their processes out the window. The rest of the article describes how they peeled-off the industry's assumptions about car making (in general) and electric cars (in particular).

To me, one of the most interesting things that this article is the fact that they eventually realized that they cannot afford to just keep up with the Japanese car companies. They cannot play it safe. They had to "leapfrog" the competition and force them to follow their lead. This is the only way they could regain the technological edge.

The Volt is not available to customers yet. And it might still be a while before it is; But, according to the article, other car makers are already using the Volt's "technology" to design a new generation of electric cars. Even if the Volt never becomes a commercial success, the strategy already paid off for GM as it re-established them as innovators in their industry.

Labels: design, work

• 0 Comments

This morning, I received an letter from WinZip Computing. In this letter, they were respectfully asking me to make sure that no unlicensed copies of their software was being used at our company and to prepare for a call from their representative that will assist us in our audit.

I'm going to channel Seth Godin here but that was an awful piece of negative marketing. The letter is full of words and phrases like: "It has come to our attention" and "internal compliance". Nowhere in the letter do they tell me what their software can do for me or my organization and why it would be a good idea to give them money instead of using what is available for free in my OS or on the internet. Don't get me wrong, I don't mind paying for software, I make my living from people selling software. But it has to add value.

What is more ironic is that I got this email because we were a WinZip customer. We bought licenses a few years ago when there was a compelling reason to use their software. Now that the reason is not so compelling, they "threaten" me into compliance instead of telling me why I should continue to do business with them. If I was not a customer of theirs, I would not have gotten this "request for compliance".

There was an email address on the letter and I will follow-up with them with a letter thanking them for the reminder that I should let everyone on my staff know about the existence of excellent WinZip alternatives like the free 7-Zip. And that they should uninstall WinZip to be compliant with their license requirements.

Labels: work

• 0 Comments

Web developers get no respect. I swear this is the sentence that I used the most often in the past few weeks.

I have said that sentence in frustration because I had to fight the perception that web development is easy. That any developer (except maybe for a VB developer) can do it. This perception is ingrained at all levels of software organizations. From the developers themselves all the way to management.

There is a pecking-order, a totem pole where developers can be classified based on what kind of developer they are. You won't find that description in any programming book. This is not explained in any school curriculum. But it is there nonetheless; implied in the way projects are funded and staffed. It is often assumed that the people at the upper echelons of the order can (when they are coerced or there is no-one else available) do the work of anyone located below. Conversely, it is assumed that you're going to be in a world of hurt as a manager if you are forced to use a developer at a lower level to do some work "above his skill".

Some might argue that Linux kernel hacking is measurably more difficult than ASP.Net web development. That might be true but I don't think that it is so much more difficult that we can assume that it is impossible for a web developer could ever undertake a Linux kernel project. I think that we just have to understand that making a switch in programming discipline requires a certain level of learning. Whether you're going up or down the totem pole.

We have experienced the "going down the pole" phenomenon recently at work. We had an exiting project to complete that was a Java-based web project. We were short on web developers to complete the project so, naturally, it was assumed that if we put a bunch of Windows VoIP developers on the project, they should have no problems completing the work. After all, it's only a web project, how hard could it be?

A few months and a lot of overtime later, we successfully delivered the project. But it turns-out that it was a difficult transition. Everyone involved had to brace for a rough ride and pull together to make it work. It was not as easy as expected. I hope that the developers that were assigned on this project have a new found respect for web developers.

In my career, I have worked at pretty much all the echelons of this totem pole and I felt that I had earned my stripes. But recently, I have been involved in a lot of web development and I have noticed that the perception of my coworkers towards me was different. I have the stigma of the web developer. I do easy stuff now.

I think it is time we get rid of the totem pole. Working in software is challenging enough without the attitudes and the disrespect.

Labels: work

• 5 Comments

Innovation is the creativity are the holy grail of employees everywhere. Pretty much everyone wants to work for an innovative and creative company. Manager want to manage hot, creative teams that deliver new innovative projects. CEOs want to be CEO of IDEO.

Employees drool over pictures of the office space at Google. The read articles about the kind of innovation that Blizzard brought to their work environment. They all think that this is the hallmark of a cool, creative environment. Put your people in a great office and give everyone a Nerf gun and you're done. I think that I used to think that too.

I am halfway into the art of innovation and I realize now that this is not about the office space or the product. It is about the DNA of your company. When you are a creative/innovative company, everything you do is done to support this. From the products/services you chose to offer all the way to the people you choose to hire. And of course, to a certain extent, the office space and furniture.

The hard realization for me is that I work for a successful company that is focused on quality production much more than innovation and creativity. This means that the DNA of the company has coerced it to grow to be an effective product delivery machine. It has hired the best software people to predictably and reliably deliver products.

This means a lot of things. For example, for most of our employees, work day starts at 9:00 and ends at 18:00. This is something we advertise to prospects that we interview. This is definitely something that becomes "untrue" when most of your work is creative in nature. Creativity might happens at odd hours and requires that you be fully absorbed into the process.

So the challenge for a company like ours if we want to become an innovation powerhouse is the significant changes to the core values of the company on the way to get there. There are a lot of examples of successful companies that started-off with that core DNA. Does anybody know of a company that reinvented itself all the way to the core and managed to turn it into a success?

Labels: work

• 0 Comments

Go sens go!

Labels: fun, work

• 0 Comments

This one has been brewing in my head for a while. Maybe I am too harsh. Maybe I am getting soft in my old age. But it has reached a level where it is more annoying to me than I can handle.

Can you guess what one of the favorite topics of conversation is right now in the hallways where I work. Developers are laughing it up about the latest "stupid" answers that such and such recent candidate gave in a job interview.

"Can you believe that this guy claims to have extensive web experience and doesn't event know the encoding scheme of the ASP.Net viewstate object?"... or some such nonsense.

This has become so common that it slips in casual conversation. It even slipped as an example in a recent training session. People think nothing of it. They think that it is ok to make fun of some guy they don't know because he failed to answer some obscure technical question about C++ multiple inheritance and its effects on the "object-oriented-ness" of Java or something.

This is even more annoying to me because I have a hard time believing that this behavior stays behind closed doors. I am also having a hard time believing that this does not transpire into peoples attitude when they interview candidates or they meet people at job fairs or other industry events. Events where they represent my employer. Ultimately, these people represent me and my livelihood. It annoys me that they act like "know-it-all" jackasses that think they can still behave like they are in high-school.

This goes against my values and I think that this goes against the values of my company. This is not how we treat customers, employees, candidates and people in general. Period.

Sorry for the rant... I just had to vent.

Labels: work

• 1 Comments

For one of our projects, the customer insisted we use Maven as our build system. At first, I thought that this was a good idea. I had read about this tool but I had never used it in a real project.

The system is easy to install and is actually pretty good at building the software. There are plugins to tie-in with pretty much all the development tools in our toolbox.

As the project progresses, I have a constant doubt in my head about Maven. About the effect it has on the project and our ability to create a stable cutoff of the code for our customer when it is time to deliver.

Then I read this post in Charles Miller's blog. That pretty much gave me the words to express my concerns.

Labels: tech, work

• 0 Comments

Ok, so I finally did it. I migrated my email to GMail. (Thanks to Mathieu for his words of wisdom)

Before GMail, I had the following setup:

• Computer at work running Outlook (always on, has spambayes on it and all my rules for dealing with mailing lists and whatnot)
• Windows Mobile 6 device that I use for voice and data
• Computer at home without an email client. I used the web access of our ISP to access email.
  

To be able to access my Inbox from all 3 locations, I setup my Outlook at work to leave mails on the server for 7 days. This meant that I could get access to current mails from anywhere. However, none of my spam filters or email rules applied to the emails on the server. I ended-up sorting and generally dealing with the same emails multiple times. Not to mention the fact that the spam remained on the POP server for me to download with my mobile device.

So my plan was to move everything to Gmail and use the IMAP functionality to keep everything in sync. The process was relatively painless but there are a few things to watch for. So, if you are interested, here's how it went for me:

1. Changed my Outlook settings to remove the emails from the POP server. I didn't want to deal with those emails that I had already dealt with.
2. Once the POP server is clear, I deleted the POP account from Outlook. Essentially stopped the delivery of messages to my inbox.
   
3. I created the IMap account for Google. This created a new "store" in Outlook with [GMail], Inbox, Junk E-Mail and Sent Items folder. (Howto)
4. I move emails from my old inbox into the new inbox (drag and drop). Once that was done, I went to gmail to validate that the emails had been transfered properly.
   
5. I then setup GMail to read new email from my POP server (Settings/Accounts) tab
6. I also setup GMail to use my business address as my default "send mail as" address.
7. I sent myself some test email and voila.
   

I was functional again. With my inbox synchronized on the gmail server. I setup my windows mobile device to access gmail.

To complete my setup, I had to do the following steps:

1. Change my spambayes settings to read incoming emails from the new inbox and deliver suspected spam in the gmail spam folder (under [Gmail]/Spam)
2. Use the gmail web interface to recreate my mailing list rules.
3. Transfer my >1.5 Gigs of email in my PST files to the gmail server (drag and drop)

So now, I am fully functional, I have search capabilities through the gmail interface and I have a synchronized mailbox. There are a few things to watch for is you decide to follow these steps and migrate:

1. When outlook deletes an email through the IMAP interface, it doesn't go in the [Gmail]/Trash folder. It just gets unlabeled and lands in the [Gmail]/All Mail folder. For now, I am not that worried, I still have 2.5G of free space on gmail.
   Note: If you use Thunderbird, you can set it up to use the [Gmail]/Trash folder as its trash folder and it works perfectly.
   
2. If you have gigabytes of legacy emails to transfer, it is possible that google will suspend your account momentarily. They have a feature that detects this as a suspicious activity. My account was suspended for approximately 10 minutes when I tried to transfer my Sent Items folder with >9000 emails in it. When it came back, I resumed the transfer in batches of 1000 emails.
3. Oh and outlook is completely unresponsive when you transfer emails so, do this when you don't need access to your email (like at night)
4. You lose some of the Outlook functionality (like search folders). However, you gain the awesome search power of Google through the GMail interface.
   Plus, the "label" system in GMail lets you achieve a similar kind of functionality. Essentially, the same email can be in two folders at once. Because folders are labels. GMail provides the "starred" label to track items that you flag in outlook. They will reside in both their "container" folder (like the Inbox) and the starred folder. This is a lot like a search folder.
5. If you setup your outlook account to send emails through the GMail SMTP server, your will notice that GMail adds a copy of sent emails automatically in the [Gmail]/Sent Mail folder. Outlook will also make a copy in the Sent Items folder of your personal folder PST. You can disable that in Outlook if you don't want 2 copies.
   

Labels: gmail, tech, work

• 2 Comments

This morning, I had a need for a spoon and there was none. According to the "rules of conduct" it became my turn to empty the dishwasher. I saw this. (took a picture with my cellphone, bad picture)

It took years to get the team to actually fill the dishwasher and push the start button.

But most of them cannot be bothered to pull the drawer all the way out to place silverware in the open areas of the basket. They'd rather open it barely and jam their knifes and forks in the first slot of the basket.

And believe me... they were jammed. I had to force them out.

Can someone explain this to me?

Labels: fun, work

• 0 Comments

When Google announced that they were adding IMAP support to GMail, I immediately thought that this was the end of my 3-locations-for-one-POP3-email-account-problem. I immediately signed-in for a GMail account and waited for the IMAP option to be enabled.

You see, my plan was to have GMail read my POP3 email account (company email) and that I would use IMAP from my 3 machines (Thunderbird at home, Outlook at work and Mobile Outlook on my smartphone). It was going to be blissful, email unification heaven.

Today, the IMAP option was enabled on my GMail account. It works (just tried it). And now, I am second guessing myself. Can I trust Google with my company's private email? Not from a reliability standpoint (can't be much worst than our ISP), but from a privacy standpoint?

Anyone out there with a good answer?

Labels: tech, work

• 1 Comments

How can our industry be considered seriously when people in the industry still write articles like these: 10 types of programmers you’ll encounter in the field.

I understand that this is meant to be humorous. But don't look further for a reason why enrollment in C.S. programs in North-American universities is way down in the pits. The image that the general population has of people in the software industry is skewed.

I work in a company with over 100 software "people" (QA specialists, programmers, project managers). The people I work with are well-adjusted, sociable people that dress normally, eat a salad once in a while and take a daily shower.

I am sure that there are jobs in software where you are more likely to encounter the archetypal software guy. But it is the exception. The halls of most software companies are populated with a mixed group of interesting people with varied interests and hobbies. In fact, a lot of software people are into creative things like music, custom cars or movies.

Not only that but, unlike the stereotype, the halls of my workplace are usually empty by 6:00pm. People don't sleep at the office in piles of take-out food.

Labels: work

• 0 Comments

Recently, someone at the office used a permanent marker (accidentally I hope) on the whiteboard in the main conference room. As the term "permanent" implies, the whiteboard is now ruined.

So I thought it was the perfect time for a little experiment. Can a whiteboard be resurfaced with common automotive maintenance products? So I brought from home my sander/polisher, a jar of polishing compound, and my trusty TurtleWax super hard shell automotive wax.

I buffed the whiteboard clean with the polishing compound, cleaned it with household cleaner, dried it well and applied a generous coat of wax. I waited for the wax to harden, polished the surface and now... I am waiting for the results.

The whiteboard looks new. It is all white and shiny. But will it erase without leaving marks?

Labels: fun, work

• 3 Comments

Recently, I got an email from a colleague. You know, one of those 2-3 liner email with just a little bit of information. And 25 lines of corporate signature. I had trouble finding the actual message.

Whadoyouknow... Scott Hanselman had a posting about that just recently.

Scott Hanselman's Computer Zen - Email Signature Etiquette - Too Much Flair?

Labels: work

• 0 Comments

Where I work, we are interviewing and hiring a lot of engineers recently.

We are always looking for new help and techniques in interviewing. Scott Hanselman has an issue about that in his podcast.


HanselMinutes - Hiring and Interviewing Engineers

Labels: tech, work

• 0 Comments

Oh man... I've been on the receiving end of this strategy a couple of times. Company calls to get a quote on development with a sketchy requirement. We provide a quote and they string us along refining the requirement until we decide to tell them we're not interested.

They they take the detailed quote and use it as a requirement to get pricing from an Indian firm... Neat.

Never Pay For Application Development Services Again

Labels: work

• 0 Comments

Today, I just surfaced from a rather important feature release in our largest projects. It was a really cool feature and went relatively smoothly. In the end, everyone pitched-in for the testing and it made me think about two tools that people have recommended to me but that I haven't had the time to test.

STAF (Software Testing Automation Framework)

And

QATraq (test case management software)

Labels: tech, work

• 0 Comments

In this blog, there is a boatload of information about the decisions taken by the UI team at Microsoft when they redesigned the user interface for the new office suite.

Hours of good reading ahead.

Jensen Harris: An Office User Interface Blog : The Office 2007 UI Bible

Labels: design, work

• 0 Comments

Recently, the company I work for acquired a user experience design firm. They are a group of folks that I have known for a while and with which we have successfully completed many projects.

Although it is not a corporate objective for me, I decided to make it my personal mission to better understand what it is they did. I had a pretty good idea of what that was but I needed something concrete. Walking through a bookstore this weekend I stumbled on About Face 2.0: The Essentials of Interaction Design and immediately started devouring it. After a few chapters, I am starting to understand.

For a guy like me who has been in the software industry for over 10 years now. This book is a great eye opener. For once, it is us (the software guys) who are made to feel like idiots instead of the users. Most of what we've been doing when interacting with users is wrong.

The book describes the basis of "Goal-Directed design". How a good interaction designer will create a design that helps the user achieve its goals. Throughout the course of the book, you learn about some design axioms like:

• Nobody wants to remain a beginner
• Imagine the user as very intelligent but very busy
• Don't make the user feel stupid
• Design for the probable case; provide for the possible case
• Ask forgiveness, not permission
• Disks and files don't help users achieve their goals

And a whole whack more.

This book is not about turning people into interactive design practitioners. It is about understanding the value of good design. I would definitely recommend it to anyone involved in the creation of software.

Labels: design, work

• 0 Comments

This document from Microsoft is a pretty good summary of secure application writing practices. It also is loaded with security checklists (if you're the checklist type of person).

This is not a "how-to" for application security but it serves its purpose well as an "awareness enhancing" tool.

(via Greg's Cool [Insert Clever Name] of the Day)

Labels: tech, work

• 0 Comments

I was reading here: "[...] how in love with ourselves most of us developers are, as we if we were great artisans forging the next renaissance. Is our opinion of ourselves deserved, or are we just rude? There is absolutely no doubt in my experience that the rudest person in almost any enterprise can normally be found in the IT department."

That surprised me quite a bit. I work in a software house and most of the guys here are quite gifted technically and still manage to stay out of the "rude" category. I would actually say that the majority are amiable. And that is quite a powerful statement considering our lab houses more than 50 software engineers.

Maybe the author's comment only applies to companies where software is not the primary focus. I wouldn't know, I have worked in software companies all my professional life. What I really wonder here is: Why do people put up with rude IT people? They wouldn't put up with a rude sales guy or a rude HR representative.

Labels: work

• 0 Comments

I am currently involved in a project to write a good-sized web application with lots of dynamic content (yes, Ajax and all that). The application was experiencing a dramatic performance degradation as the user kept using it. I knew that Internet Explorer had a well known problems with memory leaks caused by its implementation of the DOM. But this was getting ridiculous: It was leaking something like 6 Megs or RAM every 10 clicks or so.

Yesterday, the Drip IE Leak Detector saved me from many days of frustration. After loading the code and building it, I was able to pinpoint the source of the leaks (One was in the TabContainer of Dojo, the others were in the Form and DatePicker component of Tapestry 4.0.2)

Without the help of the leak detector. I would probably still be trying to find these leaks.

Labels: tech, work

• 0 Comments

Software projects have a reputation for costing too much and generating very unpredictable results. In this age of cost-consciousness, the trend that I am seeing in my customers is to try to avoid that problem altogether trying to strike fixed-price arrangements with a contractor. From a business point of view, this just seems to make sense. To ensure that they get what they pay form, they will use contracts and a big specification document as a yardstick by which to measure the achievement of the objectives.

This is far from someone just asking a contractor:"How much is it to build me a software to track my sales?" but it reminds me of a movie called bedazzled. In that movie, a guy strikes a deal with the devil and gets a certain number of wishes. In the first wish, he wants to be rich. The wish is granted but he is now a Columbian drug lord with people trying to kill him. As the movie runs its course, the guy gets much more precise in his wishes but he consistently forgets a details and never gets what he wants.

Of course, in the movie, the devil tries to find the flaw on purpose and takes advantage of it (what do you expect... She is the devil). Assuming the contractor you choose is not trying to build something you don't want on purpose, the system described in the specifications might not be the system that you really want or need.

This being said, I will sometimes find myself on the contractor end of such a project. The customer realizes (often after discussing various alternatives with me) that the system that was described in the specification doesn't solve their particular problem. Because the budget is fixed, I find myself with few alternatives. I could finish building the original system and have an unsatisfied customer. I could agree to a change in the original plan. The problem there is that any change will have an impact on cost. That increase in cost will have to be spent either in actual dollars or by removing some functionality. This will no doubt be interpreted as a failure of the contractor to provide accurate estimates. I'm not sure what is worst.

I wonder about the feasibility of micro-engagements where the contractor and the customer would negotiate an arrangement on a feature-by-feature basis. Some sort of Extreme-Contracting where the contracts would be short enough (4-8 weeks) that the content of the deliverable would be unambiguous. If the requirements changes mid-stream... The work lost has already been accounted for and approved. I think that this is a model when the risk of going into a software project is more clearly spelled-out and is shared more equally between the contractor and the customer.

Labels: work

• 0 Comments

I spent last week away at a meeting and I can say without a doubt that it was the oddest meeting in my career. First, this meeting was odd because of its scope. There were 17 attendees at that meeting from 3 separate companies. The attendees were all related to the same project but spanned the full range of people that make a project: programmers, sales, lawyers and executives. Many of the attendees had to fly in from somewhere else (including yours truly) and most of the people there all had another focus in their work than this meeting. The opportunity cost created there was huge. My thought was it was in everyone’s better interest to make the most of it.

But, what made this meeting really odd for me was that, with only a handful of exceptions, everyone had a laptop computer opened. Once the introductions were over, slowly, one after the other, people started typing away. (Except of course for the person that had the floor at the time) A quick glance around the table confirmed that they weren't typing notes. Most of them were typing emails in Outlook or even engaged in IM conversations. (the room was wired) The ones that didn't arrive early enough to get a seat at the table were sitting around the room in the cheap seats typing away on their Blackberry.

Surprisingly, by the end of the week, we had accomplished a significant amount of work. Still this whole experience left me with a bitter aftertaste. My company had invested a significant amount of time and money (flight, hotel, opportunity cost) to go to a meeting where people talked but hardly anyone listened. I was kinda peeved and I swore to myself that if I ever had the opportunity to host such a meeting, the internet connection in the room would be "unfortunately out of service" and that I would hide all the powerbars except for the one that powers the projector.

Now that I have slept on it for a day or two, I am not sure that it was all bad. Because of the scope of the meeting, there were periods of time when the executive level people couldn't care less about this conversation and, similarly, other discussions where the technical guys would have preferred to go through a root canal operation than to sit there and listen to business people discuss contractual issues. This is where the access to email mitigated that opportunity cost.

When all is said, this was probably a symptom of a meeting that needed refactoring. A little like a programmer that writes a function that is called validateAddressesAndSend() for an email client. In that case, the inability to choose a simple action verb to be the name of the method illustrates that the method might require some refactoring. In this case, the fact that only a segment of the attendees were participating in any given discussions was probably a hint that the meeting could have been refocused.

Labels: work

• 0 Comments