Spreading the Word

by Nick Friday, December 29, 2006 10:45 AM

It all started with Jeff Atwood, and then I saw another one from Omar Shahine, so I'll add my own to the mix.  Instead of talking about simplifying the login process, or going to a .com site faster, I'm going to talk about opening up Windows Explorer.  Hopefully Jeff won't take offense to stealing this format, and helping to start a dreaded blog meme.

Every computer with Windows has Windows Explorer, that everyone has to use to manage their files.  It's pretty much unavoidable that you'll have to use it most every day.

As much as we see Windows Explorer every day, you'd think we would have mastered it by now. Unfortunately, we haven't. Here's what I've observed users doing, over and over again:

  1. Click the mouse on the Start button.
  2. Click the mouse on Program Files.
  3. Click the mouse on Accessories.
  4. Click the mouse on Windows Explorer.

Every time I watch someone do this, a little part of me dies inside. And I see it all the time*.

I'm not just talking about casual users like our parents. I'm talking about our fellow software developers, and other users who work with the computer for most of the day. People who really should know better.

What kills me about this is all the needless, painful mouse clicks. You've needlessly clicked your mouse and waited for menus millions of times-- just add a little Windows Logo+E to the mix! I'm no keyboard Nazi. All I want is to save users a few precious seconds of their day as they slog through their computer files during their work day. And it's so darn easy:

  1. Press the Windows Logo button + E

See? Wasn't that nice? Now it's your turn to play Keyboard Appleseed and spread the word so your fellow coworkers can spend less time opening programs - and more time getting actual work done.

* A variation I also see is when people right click on the Start button and click Explore from the context menu.  Although it's fewer mouse clicks, it needlessly takes you deep into your directory structure where your Start menu shortcuts are stored, and so is also a waste of time.

You Know You're a Geek When...

by Nick Friday, December 22, 2006 10:15 AM

... reading a post about Beowulf first conjures memories of the distributed computing project, and not the original Old English poem.

BarCamp Madison Details Announced

by Nick Thursday, December 21, 2006 3:39 PM

The dates and location for BarCamp Madison have been finalized.  It will be March 3rd and 4th, 2007 at the Inn on the Park Hotel.  The next planning meeting will be held in early January, so stay tuned to the Current Event page for details if you want to participate.

Happy Birthday Edvard Munch

by Nick Tuesday, December 12, 2006 9:57 AM

One of my coworkers IM'd me this morning...

See Google's main page?

Every now and then they change the logo on the main page, either to celebrate a holiday or some other event.  Today is Evard Munch's birthday, and they have a Google Logo featuring one of his most famous paintings, The Scream.

As it happens, one of the many trinkets that fills my cube is an inflatable version of the main character in The Scream.  I also have a version that I use as desktop wallpaper on my computer sometimes.  So I wish a very happy birthday to the now departed Edvard Munch, who so aptly painted an event that I sometimes want to recreate at work on a daily basis.

Brrr... It's Cold In Here

by Nick Thursday, December 07, 2006 11:39 AM

Our code froze!  A lot of companies include some sort of code freeze process in their development process, but few truly honor the meaning, and instead simply use it as just another artificial milestone that they can celebrate.  But what exactly is Code Freeze, and why is it useful?  At a very basic level, code freeze simply means that no more changes are allowed to be introduced into source control.  Generally this also means that all defects have either been fixed, or they have been reviewed and its been decided to either not fix them, or delay fixing until another release.  Usually the first build after code freeze is declared a Release Candidate.

The one important part of the code freeze process, which many companies fail to implement is the shelf period.  If you freeze code, and then immediately release your software the next day, then code freeze is pretty meaningless.  I personally recommend at least a one week shelf period after a release candidate (depending on the size and complexity of the application).  During this period of time, your developers and testers should continue testing and using the application.  Because nothing new is introduced into the code, this provides a period where everyone can feel confident that things are going well, and extra regression testing and user acceptance testing is performed.

Code freeze also signals an important change in the development process.  Before code freeze, defects are fixed at will by people, and changes can be introduced rapidly.  During code freeze, extra scrutiny is placed on any defects that are submitted, and generally only high priority defects are considered for fixing after a review process which includes the development lead, test lead, and project managers.  Defects that include changes to functionality should be flat out rejected, and only defects to already included functionality should be considered.  Also, any code changes that are made during the freeze must be associated with one of these defects, and must be reviewed by another developer on the team before it is to be included in another release candidate build.  Any changes made to the code that aren't related to the defect should be rejected by the reviewer.  I don't know how many times I've seen people try to sneak in changes during code freeze, just because they wanted to "clean up the code".  Now is not the time for those types of changes.  The reviewer should also verify that the change is safe, and that it actually fixes the defect.  The idea is not to introduce a new bug when trying to fix this one.

If multiple release candidates are created, it is up to project management whether the code freeze time will be extended.  This is generally done after examining the nature of the defect, and the also the size of the change, and how much code was effected.  If something as small as a spelling mistake is found, then code freeze would not be impacted.  However, if a generic library method is changed that is used by various parts of the application, then you'd want to extend the freeze to regression test the affected areas.

Remember, code freeze isn't just another meaningless milestone.  It should include process change, and should help to introduce confidence and stability to the software development process just prior to deployment.

About Me

Nick Schweitzer Nick Schweitzer
Wauwatosa, WI

Contact Me
I'm a Software Consultant in the Milwaukee area. Among various geeky pursuits, I'm also an amateur triathlete, and enjoy rock climbing. I also like to think I'm a political pundit. ... Full Bio

Community Involvement

Twitter

Archives

Flickr Photos

www.flickr.com
This is a Flickr badge showing public photos and videos from Nick_Schweitzer. Make your own badge here.

Standard Disclaimers

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2017 Nick Schweitzer