Think Twice, Code Once. (An MWRC Poem)

April 6, 2013 Project Management Comments Off

The right side of my brain helps me make things rhyme
The left side keeps it all in time
Whats in between helps me learn and perceive
But do I Believe,
I have the answers I need?

Ours is a culture with pride in logic and reason
But do the ones and zeros truly have meaning
Does your software have feelings?
Stay Tuned
This may be revealing

Work harder they said
We can rest once we're dead
What is the Opportunity cost
Of this lack of mental floss?
So many questions and no time for thought

Maybe you should sleep on it
Let rapid eye movements give way to improvement
Solutions reduced to abstract illusions
Fast asleep and hard at work
Generate painless solutions

So we've chosen our tools
We've lined our minds with patterns of design
Muscle memory translates brain waves to square braces
And a faint blue glow on our end users faces

Blue glows become blue screens
and sad macs bombs and disasters
Did we fail to think or fail to see
Or were we just told to work faster?

Five times we ask why things went awry?
Why? Because the computer does what you tell it to
Why? This solution doesn't follow the rules
Why? The analysis was done by fools
Why? We missed an opportunity for code re-use
Why? The user may have just been confused

Problem solving is a feedback loop
Think, Learn, Repeat
The right question IS the right answer
Take Time for contemplation
and you just might get there faster

Relax, Your brain is hard at work
Maintaining focus
A puzzle piece is placed precisely
With you unaware of its locus

But.. The joke is.

A computer walks in to a bar
Or crashed onto the surface of mars
Because you told it to
Think twice, code once
and you'll go far

Thoughts on Remote Work and Distributed Teams

April 6, 2013 Project Management, Software Development Comments Off

Coming from companies with full remote work policies I had quite the culture shock integrating in to my current day job. Initially an exception was made because I was living in a different state and I would work remotely for several weeks at a time and then come in to the office for an approximately equal amount of time living with relatives in the area, and then return home for another cycle of the same. A few nice things happened because of my partial remote situation. First off, day job felt it had to create remote work policies so that other team members could have that capability and this benefited the entire team. Secondly tools like IRC began to be used as communal chat to allow a centralized method of communicating with the entire development team.

Eventually I moved to the area and was expected to be in the office most of the time. I knew this was always the expectation but the first year or so of mostly full time in-office employment was pretty miserable for me. At that time I had been self employed, remote employed, or consulting for over ten years and the idea of having to go in to the same office every day and work to a fixed schedule was hard to swallow. I know most office or knowledge workers do it but I still struggle with it today and I believe that a good remote work policy should be a solid component of any modern software team.

Now we have a partial remote policy, and many of our developers take advantage of it. I am managing the team and I have developers in two different offices and others occasionally at home or elsewhere and I have come to realize that having a distributed team is very difficult if the rest of your non-remote company doesn't have a culture that supports it.

My last employer was a company with full remote salespeople, developers, phone support personnel and managers. Their culture was built around a distributed team and it worked really well. Now as a manager at my day job it is almost impossible to work from home without feeling tense because I'm missing out on some communication or the support team tries to pop in my office instead of call or catch me in IRC. I even find myself feeling out of sync with some of the remote people because I allow myself to succumb to the culture of being always present and accounted for, at the specified time, in the specified place.

One of my team goals for this year is to iron out remote best practices that make more sense. Consolidate communications in ways that help distributed teams and push for policies that demonstrate an understanding and acceptance of a remote culture. To do this we need to start by enforcing communication policies within and to my team. As I review what will need to be done it turns out to be much more difficult than I would have expected. There are both habits and politics involved and neither of those are the kind of thing you want to have to overcome.

I want to start by better consolidating communication. It seems like this would be an easy thing. We already have an IRC channel devoted to daily development operations so just make all initial communications with my team happen here. This quickly breaks down when you realize we are company with over 150 employees and my team is only ten of them. So now we must augment that policy to say that if you are not in IRC the best first line communication with my team should be via email. Great, problem solved. Not so fast. I have another general policy in place that you should not communicate with developers via email and expect an immediate response. Email is not an instant communication medium. Important communications can and should be emailed for posterity but if our servers are down or a feature is completely broken in production we need to know immediately and an email is not the way to do that.

So where do we go from here? Normally what happens now is someone on our support or qa team will get out of their desk and walk across the hallway to the development office and let us know there is something wrong. Telephone communication happens across our two offices but intra-office it is almost non existent. This is because most of the developers do not have office phones. I am almost never at my desk so the pop-your-head around their monitor culture is pervasive.

I know how to be part of and manage full remote teams. Learning how to manage a semi-remote team without a remote culture is proving difficult.

Rails Installer for Windows

January 18, 2011 Project Management 183 comments

My good friend and business partner Wayne Sequin has been working hard on a Rails installer for windows platforms with the help of Luis Lavena and several Windows savvy rubyists and the support of Engine Yard. The goal is to make the Ruby and Rails installer packages the standard for getting started with Ruby or Rails on Windows platforms. The project looks great so far. You can find it here http://railsinstaller.org/

My take on the Mac OS vs. Windows argument

April 14, 2009 Project Management 1,375 comments

I have worked with, networked together, programmed, repaired and played on computers for the better part of the last two decades. While this by no means makes me an old wizard, it does mean that I should have something to say about why I might prefer one platform over another. It has been part of my job since my first IT position to advise people about what technologies they should be using to get the job done and I do have a few things to say on the matter. The bottom line is that it really has nothing to do with
Apple Vs. Microsoft anymore. Mac OS is a desktop client version of Unix. Apple has succeeded in creating what is probably the first commercially successful desktop pc that runs Unix and this means a lot. It is now about Windows Vs. Unix and its cyberpunk cousin Linux.

Security: Unix was born to facilitate hundreds or thousands of users or network connections and had begun to be battle hardened long before Windows decided to release its first networking edition. If you'd like some historical perspective you should read The Cuckoos Egg, by Cliff Stoll.  The truth is that the Unix operating system model was created for the very kind of computing we do today. The protocol we use to transmit data packets back and forth (TCP/IP) was developed on Unix environments for what we now call the Internet. Almost anyone using a computer is accessing a loosely connected group of services that could be hosted anywhere in the world. Windows was created to be a standalone operating system on a single PC and the explosion of the internet has meant that it has been trying to adapt itself to a new use model for almost two decades.

Usability: Apple did not make a better operating system. They took a more functional and secure operating system that already existed and made it more usable. By starting with a solid platform Apple was able to focus on aesthetic and that is really what they are best at. It seems that they already know they have a solid platform so they spend more of their time making it usable and friendly whereas it seems that Microsoft has been concentrating on putting a new coat of paint on the same old user interface elements. I have not seen anything in the windows platform that I would consider an innovative direction in user interaction since going from windows 3.1 to  windows 95 and that was almost 15 years ago. They did have a few bug light* features in vista similar to the expose feature in mac OS X.

Resiliance: Unix is built upon a much simpler and obvious architecture than windows. Look no further than the Windows Registry and you should see my point. Its a pretty good rule of thumb that the less moving parts something has, the less likely it is to break. In this case simpler is better.

Perception: I've spent quite a few years of my life in colleges and universities and I've found that nowadays academics seem to use linux/mac to an overwhelming extent. I've also seen IT managers at some of the more progressive firms say things like  "I expect a pro to use the best tools and that means using Mac OS". I've seen plenty of flikr shots of someone from microsoft doing a presentation from a mac book pro, and while this is by no means proof of anything it does go a long way towards buidling up the perception that Apple makes better computers.

Personally I do not believe that apple makes better computers but they do make computers, microsoft does not. Apple markets its computers and its operating system as a lifestyle and a lifestyle choice. They have made themselves a symbol of an open mind and a thick pocket book and these are not misconceptions. Their computers are high end and It takes an open mind to break out from the norm. Windows was the norm and every time someone switches over they are being open to the idea that there might be something better out there.

Unfortunately this latter point is probably what drives sales and the real importance of a good computing foundation is being lost on most of the folks who buy computers. Windows came from dos and there are quite a few lines of legacy code in there from its grandfather. Mac OS came from Unix and there are quite a few lines of legacy code in there from its grandfather.  Remember that the apple doesn't fall far from the tree.

*things that make you say ooh and ahh but zap you when you get close to them

Bash Primer for Beginners

April 12, 2009 Project Management 179 comments

If you are working with OSX or *nix flavored systems and you are not already automating mundane tasks with bash or some other scripting language than you must enjoy repetition.  I migrated over to OS X a few years ago and although I had been integrating Linux and Apple Operating Systems into the Windows networks I was running It wasn't until I finally made the switch for personal use that I saw the light. The power of the various *nix command line interpreters and shell scripting environments makes it tough to ever look back. I'll be adding to this primer over time but I'm basically doing it to remind myself to stop wasting my own valuable time on simple repetitive tasks.

Available Libraries: Inside of your bash scripts you have access to anything you can type at the command line regardless of their underlying language. Commands like 'ls' (list all files in a directory) and 'grep' (regular expression parser) are available to you in your scripts.

Where to put your scripts If you define a set of functions in a file you can load them in to your environment at any time by calling 'source script_name' but you will most likely want to source them in your profile configuration (.profile, .bash_profile, or .bashrc) depending on how your environment is configured. You can store a bunch of scripts in one place with any extension you'd like but sh is common (script_to_run.sh) and add that location to your path variable. You can also run a script from within its directory with

  1.  ./script_to_run.sh param1 param2

Note that you must change the permissions on your script to make it executable.

  1. chmod +x script_name.sh

Shebang Line : Tells the operating system where to find the command interpreter, Make this the first line of your script

  1. #!/bin/bash

Standard Output Send the text 'Hello World' to the screen

  1. echo Hello World

File Output output to file puts the output of the function helloWorld into the file hello.txt the file will be created if it does not exist

 helloWorld > hello.txt  #overwrite file with output
helloWorld >>  hello.txt #append output to file

Variables Standard assignment syntax, prepend with $ to retrieve

  1. #assign like this
  2. VAR=5
  3. #access like this
  4. $VAR

Functions : Simple function syntax you can pass parameters in to this function and they are available as $1, $2, etc...

  1. function helloWorld(){
  2.   #for example 'helloWorld earth' would have the string 'earth'
  3.   #available witihin the function as $1
  4. }

Pipes '|' : The pipe character will take the output of one operation and pass it in to another. The following line will take the output of the ls command and 'pipe' it into the grep command returning only items in the ls output that match the string 'world'

  1. ls -la | grep world

Show hidden files in finder in OS X

April 11, 2009 System Management 372 comments

Every once-in-awhile I'll want to be able to view hidden files in the finder. You can google this problem and you'll find a lot of people with the same answer. Pop up your terminal and enter  "defaults write com.apple.finder AppleShowAllFiles True". The issue is that every time I need this I google it again because I just don't do it often enough to remember the syntax.  So I found it useful to create a bash function called showFiles that takes either True or False.

  1. #expects $1 to be  either False or True
  2. function showFiles(){
  3.  
  4.    defaults write com.apple.finder AppleShowAllFiles $1 && killall Finder
  5.  
  6. }

Now you can do 'showFiles False' or 'showFiles True'. I'll admit there are very few reasons to do this (show all files in finder) if you are proficient at the command line but sometimes I feel like being lazy and now you can be lazy too.