Benjamin Hysell – Software, Projects, and People Rotating Header Image

Tools in the Toolbox – Source Control

Oct 31st, 2009
by Benjamin Hysell.
Comments are off for this post

“Tools in the Toolbox” is a series of posts on development and design tools I use on a daily basis.

You use source control, right?

Good, I’m not going into the benefits of using source control, it should be a no brainer in this day in age.

No, you don’t use a system to back up every revision you make to your code?

Ok, here’s what you are going to do.

  1. Finish reading this blog post and then never come back to my blog again.
  2. Close your browser
  3. Uninstall all of your development tools and never write another line of code.

I’m not kidding.  If you are not using some form of source control for your daily coding activites I’m not sure we can be friends any more.  I mean, before I learned this about you I thought of us as at least friendly, but this is a deal breaker.

All snarkiness aside, source control is one of those fundamental tools like a hammer or screwdriver that needs to be in your toolbox.  Having a system that allows one to go back in time and see every change that has ever been made to a piece of code is invaluable.

Are you telling me you wouldn’t want to time travel back in time given a chance?  I’m offering you that opportunity to do so without the need of a DeLorean or a Flux capacitor.  You would turn down time travel?  Sir, I must say good day.

Won’t stop reading eh?  Maybe there is hope for you yet…let’s look at two scenerios, one with source control and one without.

It is 10pm, you should have been home hours ago.  Diner is cold, wife is mad.  You are in the office, your hard drive died at 4 this afternoon.  You have lost all of your code for your presentation you are going to give tomorrow, and you are only half way done recreating all of that code.  You have a long night ahead of you.

Try that same situation, but this time you and I are still friends because you use source control.

It is 5 pm and you are sitting down for a nice meal with the family.  You had a rough day in the office, your hard drive died right around 4 pm right after you put the finishing touches on your presentation you are giving tomorrow.  Since you use source control you have copies of all of your code in a repository on a seperate server.  You contact your IT guy, grab a spare laptop, connect to the source control server and pull down all of the code you have been working on.  You check it over, its all there.  A minor emergency before your presentation, but luckily you have avoided a full night of rewriting all of your code, and can go home and relax.  Thank goodness for a good source control system

Contrived?  Yes, but still proving the point of having copies of your work in a system off of your main development computer will avoid disaster.  Sure, you could have avoided this scenerio if you just stored a copy of your code on a thumb drive or a network drive, but then you would lose all of the benefits a source control system brings to your development environment, each done with only a few clicks:

  • One click check in process – Most systems now a days integrate directly into your IDE.  With a few clicks a copy of your code is placed into the system.  Total time, five seconds, max.
  • One click get the latest copy – When working on a team often times people make changes you’ll have to get a copy of.  Instead of bothering them you can normally right click on your project and select ‘Get latest’ to pull down the latest copy of all of the code stored in the system.
  • Compare – Allows you to take the copy of the code you are working on and compare it to the code that is sitting in the source control system for changes.  Did you accidentally erase a key section of code and then re-save your code?  Compare it and pull back that key piece of code.
  • Merge – Are you working on the same piece of code your buddy is working on?  Who has chnaged what?  One click and the source control system can help you merge his changes with yours.
  • Shelve – Are you working on a cool new feature only to have an emergancy bug crop up that needs addressing ASAP?  Take your code and put it on a shelf in the source control system.  Shelving code takes a snap shot of your current code and places it in a special area allowing you to go get a new copy of your code from the repository, fix the bug, check in the changes, and then go and get the code you were working on, apply the changes, and then continue on your merry way, saving time and energy.
  • View older copies of your code – This is the “Back in Time” scenairo, you need to see changes made last month to a key algorithm, with a source control system you can go back and grab those changes since you are saving a copy of every change ever made this isn’t an issue.

I use source control for everything I write, code or otherwise.  Every document I write for this blog is backed up in a source control system.

For the sake of our friendship, please go and grab something, anything to put your code into.  I am a huge fan of Team Foundation Server from Microsoft, but SVN has been growing on me.  There is a huge list of systems out there, pros and cons, if you Google for them.

Take a hour, download a source control system, set it up, and move all of your code into it.  You might not thank me today, or tomorrow, or the next, or even late next year.  Some day, some day in the future, you are going to rely on that source control system and you will be thankful you have it.

Tools in the Toolbox – Test Driven Development

Aug 15th, 2009
by Benjamin Hysell.
Comments are off for this post

Tools in the Toolbox is a series of posts on development and design tools I use on a daily basis.

I am a huge fan of Test Driven Development (TDD).  See my series I wrote for the Viewpoint Systems eNewsletter centering around TDD and LabVIEW:

Part 1

http://www.viewpointusa.com/newsletter/2008_november/newsletter_2008_nov2.php

Part 2

http://www.viewpointusa.com/newsletter/2009_january/newsletter_2009_jan2.php

Part 3

http://www.viewpointusa.com/newsletter/2009_february/newsletter_2009_febtdd.php

Part 4

http://www.viewpointusa.com/newsletter/2009%20March/newsletter_2009_Mar.php

Although I’ve written the most about my LabVIEW TDD experiences I use TDD in all of my development endeavors, be they text based in the .NET frameworks or web based development with JavaScript.  Now a days almost every modern language has a framework available to facilitate test generation and automatic test execution.

One of the first things I do when I start with a new language is to find the TDD framework and take the language and the framework for a spin.  No longer do I bother to create a ‘Hello World!’ app, I dive right into writing tests.  My last two language adventures involving Objective-C and Ruby on Rails attest to this fact.

However, as I sit here and write this post I already hear the groans emanating from a lot of developers,

::Put on your best Sean Connary voice from Celebrity Jeopardy on SNL::

You see here Benjamin, I’ve tried a lot of development processes in the past, paid a pretty penny for them, I don’t mind telling you, for books and classes and whatnot.  None of these processes ever work.  So, I’ve got to ask you, will TDD really make my code better?  Does it really work man?

As long as there no follow up questions, then yes, yes it does work.

Post over.

Oh, you are still here?

::Damn, now I have to come up with a few explanations…::

Why have I embraced TDD and given so much virtual ink to it?

Fear.

Out and out fear.

Back-story:

When I started with Viewpoint out of college I had endured my share of ‘larger’ software projects.  I say ‘larger’ because when you are snot nosed kid in college taking a semester to build a compiler it feels like a large project.  The late nights, the team of people toiling away on the code, and all of the social events missed as we attempted to get the compiler code to compile…we felt it was a large investment of time and resources.

I learned a lot on that project, but as with all college projects, once the semester was over I would never have to revisit the code base again.

Let’s face it, when you are on a co-op, one is only engaged with a company for maybe a three month period; there is rarely enough time to finish even a small project, let alone start a new one and then go back and make changes to your original project.  Thus, the idea that one might have to support and modify their code at a later point in time was a foreign concept to me leaving college.

Naturally, things quickly changed once I entered the real world.

I’ll put you in my shoes as a young developer: There you are, its 3:30 PM on a Friday.  Your software is crashing for some unknown reason, and you desperately want to be out of the office because it is one of the last weeks of summer.  Nothing has changed in the code.  Sure, you made a minor modification this morning to about a dozen code files, but the software was up most of the day, and now all of the sudden something is very wrong.  Your software is stopping and starting every couple of minutes and you can’t leave until it’s fixed.  You can’t just drop the changes you made this morning because those changes had fixed an even larger problem in the code, and by the way, do you remember where you made all of those changes?  You wrote them down, right?  You are using source control so you could roll back everything you just did, correct?

Picture yourself in a cube with flop sweat all over you realizing this isn’t how you want to run your career for the next 50 years, living in fear of every little minor change you make to a code base.

This is the realization I quickly came to soon after I started supporting some of my own code.  Forget supporting other’s code, this was my own code, I wrote it and it was still acting up on me.  I vowed that day to never live in fear again of modifying my code and not knowing what the results would be.

Fear motivated me to seek out a methodology that would help me avoid these types of situations.  I wanted to know when I was making a code change that change didn’t have an unforeseen ripple effect through the rest of the code base.  For me, TDD provided an avenue to help me avoid these situations by forcing me to generate a full suite of regression tests that I could quickly and easily run against any changes I made and validate I didn’t create any new bugs while fixing the code.

TDD isn’t perfect, and it isn’t free.  Can you make sure all of your test cases exhaust all possible inputs into your system?  What about the time spent developing the regression test suite?  How about the time spent maintaining and fixing the test when you make changes to how your code works?  All of these items have a cost associated with them.

It is near impossible to put a monetary value on the time and money one can save from using TDD.  How do you quantify,

“Because I had regression tests I could run on my code the change I was going to make this morning never made it into the system because it broke all of the tests.  I re-architected the solution, ran the tests, and the new solution hasn’t caused us four hours of downtime.”

How can one say their design methodology prevented a massive loss of time later down the road when you never experience that loss?  How can you really prove you can save time and energy with TDD?

In my travels so far I haven’t found a convincing argument that the time you spend writing and maintaining test cases saves time and money.  Basically, I have yet to acquire a DeLorean…sure I have the flux capacitor, but I don’t have the car to put it in, drive Back to the Future, and prove that if I didn’t have a regression test suite I would be in a world of hurt six months down the road while attempting to make a minor change.

Sadly, I believe one has to develop flop sweat a couple of times in their career before they will actively seek out a methodology like TDD and start applying it to all of their development endeavors, regardless of the inability to show a future cost savings.

My Bookshelf – Rigged

Aug 10th, 2009
by Benjamin Hysell.
Comments are off for this post

I’ve finished reading my Dilbert book and have kept my next book firmly planted in the ‘fun summer read’ category. Although I’m just starting Rigged: The True Story of an Ivy League Kid Who Changed the World of Oil, from Wall Street to Dubai by Ben Mezrich, I can already tell it is excatly what I need for these long summer days. Check out my initial thoughts of Rigged in my updated bookshelf: http://benjaminhysell.com/my-bookshelf/.

Seth Godin Marketing for Makers

Aug 2nd, 2009
by Benjamin Hysell.
1 comment

I found this video the other day in my travels along the interwebs and wanted to share with the class.  For me, this was one of those videos I’m going to have to watch a few times to fully appreciate it.  Seth says he is going to move fast through his material when he starts, and he isn’t kidding.

Seth explores marketing over the ages and how the game has changed from interruption marketing (TV) to the new world order.  In the past, someone could force you to view their ads on TV (thank you, thank you, thank you TiVo), but now a days there are so many media outlets and products pushing for our attention that we are overwhelmed with stimulus and are never forced to view any marketing from anyone.

It is as if our attention is being attacked by a huge denial of service attack where so much marketing information is coming at us we decide to turn it all off and listen to none of it.

The game has changed, people need to be looking for you to find you, and most marketing and products are not designed this way.  Seth hammers home several points:

  • Your software should have marketing built in
  • Your software should be able to self market
  • Your goal is to have people want to use your software, and spread the word about your software to others

::cough Apple, cough Google, cough, cough::

Seth’s best example of one company who gets it and one that doesn’t?  Ford vs. BMW.  When was the last time you saw an ad for a BMW?  Can you go three minutes watching TV and not run into a Ford ad?  BMW pours their marketing money into the product, making something people want, and given unlimited resources, something most people would likely buy given the chance.

::That is, of course, until you have to take it to the shop, but I digress::

This is a great video for anyone who makes anything, software or otherwise.

Please to enjoy Seth Godin at the Business of Software 2008.

::After watching this the first time through I thought to myself, ‘I need to add his blog to my daily reading list‘.  Little did I realize I’ve been reading his blog for some time,  doh, http://sethgodin.typepad.com/::

Updated My Bookshelf

Jul 11th, 2009
by Benjamin Hysell.
Comments are off for this post

I’ve just finished Stumbling on Happiness and have moved on to Stick to Drawing Comics, Monkey Brain!: Cartoonist Explains Cloning, Blouse Monsters, Voting Machines, Romance, Monkey Gods, How to Avoid Being Mistaken for a Rodent, and More by Scott Adams the creator of Dilbert.


I loved Stumbling on Happiness and thought about writing a full post dedicated to it, however after going through my notes,

::yeah, I was on a plane thumbing out notes about the book on my iPhone, I was pretty jazzed up about the book when I finished it, and couldn’t wait to get to a proper keyboard.::

…I realized I was recapping the whole book, and not as eloquently as the author.  I highly suggest this book, pick it up for a fun summer read.

Check out my initial impressions of Scott Adam’s latest book here in my bookshelf:

http://benjaminhysell.com/my-bookshelf/

How Would You Motivate Howard Stern?

Jul 1st, 2009
by Benjamin Hysell.
Comments are off for this post

Disclosure #1: I am a rabid Howard Stern fan.

Disclosure #2: I actually own stock in SiriusXM at the time of this writing.

Wise Ass Remark #1: I should have really held off on buying the new iPhone last week, I could have completed my hostile takeover of the company.

::As of this writing the stock is trading in the mid 40s, the mid 40 cents a share.::

Picture yourself as SiriusXM management.  We’ll call you, Mel, for fun.  Mel you have one of the greatest radio talents ever to grace the airwaves in your possession.  Your company acquired exclusive rights to him and have him locked up for the next couple of years.  Howard moved over to your company and brought a lot of his fans with him, almost instantly paying for his contract with all of the new subscribers.

Howard is still on top of his game.  His audience still loves him and by all accounts, he is doing a bang up job.  But the stock, oh the stock price!  People could buy a share of your stock with the change they find in their couch…your subscribers might be happy, but Wall Street is not.

For the sake of this article let’s pretend there are not a million other economic, business, and social factors at play in determining the stock price of a company.  Let’s assume that the more subscribers you can acquire the higher your stock price will rise, thus motivating you, Mel, to find a way to acquire more subscribers.  Lastly, you being you, you know that there is a vast quantity of people out there willing to pay to listen to Howard Stern, they just need a little nudge to get them into the game.

Knowing all this, one might naturally approach Howard to do some promotion outside of his show; maybe do the late night talk show circuit, an interview in Rolling Stone, show up to a movie premiere…anything that would expand the reach of his voice past his own show, and remind the fence sitters who used to listen to Howard to pick up a satellite receiver.

Sounds reasonable to you…get your biggest star to make a media push, sit back and watch the subscribers roll in.

Howard, however, isn’t all that motivated to help out.

Sure he has a million and one reasons why he doesn’t want to do more press, the late shows, etc, but it really comes down to he feels he is doing a great job, as validated by the listeners, and the hell with everyone else who didn’t follow him and the stock price.  Howard, in his mind, has fulfilled his end of the contact.

Mel, what do you do with a star employee who is performing at acceptable levels, but not working to his ‘all-star’ potential?  You know Howard could step up and do more outside of his already excellent show, he could be doing things to bring in more subscribers, and grow the business.  You have seen him do it in the past, however right now he just isn’t.

What do you do?

Back to software engineering…you’ve hired an all-star developer, named Johnson, from Microsoft.  Johnson has years of experience with all the right technologies.  You pay him a fair salary for his skills and his years of experience, and once he starts working for your company you find out he is only an average manager/mentor/team member/coding machine and not the all-star you expected to show up when you hired him.

What do you do?

How do you get your own personal Howard Stern to step up, take on new challenges, and work to their full potential?

What motivates people to work harder?

Money, Power, Respect, Whatchu’ need in life.

~Lil Kim from Money, Power, Respect by The LOX featuring Lil Kim & DMX

::I knew at some point I could work DMX into my blog.  Mark another item off of my ‘Bucket List’::

Conventional wisdom says we are all working for these three items, money, power, and respect.  Let’s break each one of these down.

Money

I believe we as managers have covered the money aspect, be it Howard Stern or our fictional software engineer Johnson.  Hopefully, you and Johnson both did research and negotiated a fair salary.  Johnson came on board, and one will assume he is satisfied with his pay.  You could throw more money at him and see if that re-motivates him to work harder, but did you just create a negative feedback loop?  Don’t work up to your all-star potential and make more money?  If Johnson keeps this up, he will end up owning the company and only have to work a few hours a week.

In Howard’s case, his contract was well publicized, something to the tune of half a billion dollars for five years.  Surely, that is enough money for almost anyone to live comfortably.  Re-motivating Howard with more money would be difficult; we don’t have another half a billion sitting around to dangle in front of his face, plus there is an upper limit on how much money your company can throw at one person.

I have just finished reading Stumbling on Happiness, see my review at http://benjaminhysell.com/my-bookshelf/, once people rise above poverty acquiring more money rarely makes people any happier.

Since we don’t want to create a negative feedback loop, and don’t have any extra money laying around in this economy I’ll cross money off our list.

Power

What is power?  Power to decide what to work on, how to work on something, when to complete a task?

Power who to hire, who to fire?

Power over your subordinates, power to decide what they need to accomplish, and when?

Power to mange every aspect of everyone’s lives around you?

Power is a nice thing to have in your daily job, its nice to have some freedom to decide what to do when, and to influence those around you.

Howard has plenty of power.  He hires and fires his own staff, he chooses what to talk about every morning, and decides how and when to move his show along from topic to topic.

Will giving someone like Howard more power re-motivate him to excel?

What about Johnson?  How much power is Johnson wielding in his current role?  Is he allowed to set schedules, talk to the project stakeholders, and manage features?  Assuming Johnson already has most of these upper management ‘base powers‘ will giving Johnson more power re-motivate him to excel?

Again, no, there is too much of a potential to create another negative feedback loop by rewarding less than stellar work ethic with more power.  Plus, how much power do you want to give him?  What new powers would you give him?  For Howard and Johnson you could expand their powers over other departments, hiring and firing for the company, and long term strategy.  Are these powers they would even want?

With great power there must also come – great responsibility.

~Stan Lee

::Ha, two items off the buck list in one night, a DMX song and a quote from Spider Man::

How much power is too much when someone can’t perform the basic functions of the job you hired them for and they become absorbed doing other tasks that are not vital to their core job?  I’m going to mark power off our list as well.

Respect

Do you respect your employees?  Do you hear their ideas, thoughtfully consider them, and then respond back to those ideas with a well worked out response?  You do?  Stop reading, start your own blog, and send me a link to the RSS feed.  Why are you wasting your time reading my blog?

Listening to others and fully considering what they are saying before responding is a rare trait among most people.  What is the quickest way to make an employee not care any more?  Pay them lip service when they are talking to you about how to improve the company.  Show me someone who feels upper management has ignored them and I’ll show you someone who has turned “it” off, and is coasting through their job doing just enough to get paid and not get fired.

The feeling of people above you not caring about what you bring to the table can be a huge de-motivator.

Howard has a lot of knowledge about the radio industry, however, rarely is his advice sought or his ideas given any respect with regards to expanding the company.  Notice I’m not talking about giving him the direct power to implement his ideas, only a forum where his voice his heard and honestly responded to.

Have you been listening to Johnson and his ideas on how to streamline development?  Did you check out his ideas for implementing a more secure source control system?  How about that time he suggested improvements for the mentoring program?

Giving people respect is time consuming and difficult.  One wants to make sure any respect given is not given falsely.  People have keen ‘bullshit‘ detectors on a whole, so giving false respect is just as good as giving no respect.

Lastly, one wants to make sure they don’t give too much respect.

Give too much respect and one loses all ability to self-reflect; they become lazy, cocky, and all around, a general failure at their job.  As a manger you have to find the right amount of respect to provide and ensure your employees don’t grow a head so large it won’t fit through the front doors of your office building.

So Mel, what techniques will you use to re-motivate your own personal Howard Stern?  Will the right amount of respect appropriately given re-motivate an employee and help them re-discover their passion?

The Zappos Way

Jun 22nd, 2009
by Benjamin Hysell.
3 comments

I’ve done it.

I’ve bought shoes online.

And I liked it.

First, let me be clear, I own roughly five pairs of shoes; I am not a shoe aficionado.  I have my sneakers, running shoes, brown shoes, black shoes, and my motorcycle boots…hardly a collection to make Imelda Marcos jealous.

However what I was missing was a pair of Nike Aqua Socks, (http://www.zappos.com/product/7525588/color/191561).  I haven’t been able to find them since I was ten, and I used to love them.  Sure, they never last a whole summer as the tops wear through, the soles have zero cushion, and provide almost zero traction, but I don’t care!  My memories of using them in my youth compelled me to find a new pair that would fit my now grown adult foot.

For the past few years I have searched high and low for the Aqua Socks to no avail.  That was until I was driven to try Zappos.com after reading an article about them in Inc.

http://www.inc.com/magazine/20090501/the-zappos-way-of-managing_Printer_Friendly.html

Sure enough, they had my beloved Aqua Socks and they were delivered promptly with a promise that if they didn’t fit I could return them with free shipping both ways.  I was delighted; I finally owned my long lost Aqua Socks in a size I could now use!  They arrived just in time for my recent trip to the Poconos for some whitewater rafting.

My foot needs aside, Zappos seems to be generating a lot of interesting press and buzz on the interwebs as of late.  What sets them apart from all of the other Web 2.0 companies out there?  As I, and others, have said in the past, all they do is sell shoes.

Primarily the focus of the Inc. article and other postings is the amazing customer service, the freedom phone reps have to meet your needs, and the free return shipping if something doesn’t fit.  In my mind all of the customer service policies and practices that everyone is praising Zappos for are all necessary evils of selling shoes online.  Zappos is attempting to fulfill a shoe need, a need filled by delaying actually acquiring of said shoes by a day or two since they need to be shipped.  With this delayed gratification Zappos needs to step it up in terms of customer service over traditional brick and mortar stores to survive.

Let’s face it, if Dick’s Sporting Goods carried Aqua Socks I wouldn’t have thought twice about hopping in the car and driving the ten minutes to the mall to have them that day.  I like the mailman and all, but I’d rather not be waiting by the door for him to arrive with a box full of shoes.  Call me impatient, but when prices are about the same online vs picking up in the store I choose the store nine times out of ten.

What caught my eye in the Inc. article wasn’t, in my mind, the baseline customer service I believe a company like Zappos needs to thrive, but rather how they go about interviewing new hires,

Prospective hires must pass an hour long “culture interview” before being handed off to whatever department they are applying to. Questions include, “On a scale of 1 — 10, how weird are you?” and “What was your last position called? Was that an appropriate title?” (The first question makes sure that employees are sufficiently weird; the second, in which the interviewer is trying to goad the applicant into grumbling about his or her title, tests for humility.)

Spending an hour or so interviewing for ‘culture fit’ is a very interesting angle to explore in job interviewing.

I’ve gone on at length about my interview process, (http://benjaminhysell.com/archive/2009/02/the-technical-interview/), however unlike Zappos, I’ve never placed so much emphasis directly on culture fit.  I tend to focus on passion…does the interviewee have passion for our craft and life in general?  Normally, while exploring someone’s passion we get a pretty good sense of who they are, what they are going to be like on a day-to-day basis, and we as an interview team can see if the prospective new hire is going to click with the team.

Lately I’ve been wondering if I should retool my interview to further explore ‘culture fit’ not only from a passion perspective, but by some other measure needed in our industry.  What that measure is I’m not so sure.

I can think back through college and high school where group work was key to many projects’ success.  Have you ever found yourself in a group of people where personalities just didn’t mesh?  I have worked in a few bad groups from time to time, and compared to groups where I worked with friends the experience of working in a group where we didn’t have a great ‘cultural fit’ was not as much fun.

I took a class at SUNY Binghamton in artificial intelligence my senior year of high school with a group of college seniors.  It was spring semester for both the college seniors and me, so we all had senioritis.  However, while they were heading off to real world jobs at the end of the semester, I was heading off to Cornell to start my college career in the fall.  Let’s just say being 18 years old and hanging out doing a group project with college seniors was an amazing way to spend the spring semester.  I had a lot of fun, but that was only after we cleansed the group of “Rick”.

The class was split into groups of four, and our group happened to be a group of five.  We were to implement a 100 node feed forward neural network as our final project, a task we were well prepared to code and implement.  What we were not prepared for was Rick.

Rick terrorized the group.  I’m not sure which was worse, Rick taking tasks and never completing them, or failing to show up to 95% of our group meetings.  The four of us who were not named Rick had to spend a lot of calories doing Rick’s work, trying to track Rick down, and in general dealing with ‘The Rick Issue.’

It’s physically and emotionally draining always picking up dropped tasks and trying to chase someone down who doesn’t want to be found.  Not like Rick couldn’t do the work, he was more than capable, however we didn’t share his work ethic nor he ours.

Now picture yourself today in your job and take a Rick, if you don’t have one already, and inject him into your normal daily working life.  My Rick was gone two weeks after the project started, as he was removed by the professor from our group, however a real world Rick maybe impossible to remove from your daily life.  Are you looking forward to Monday knowing Rick is going to be there now?  I wouldn’t be.

Life with a Rick is miserable, and from the article it appears Zappos makes a huge effort to ensure Rick never gets through the interview process:

If there is a disagreement between HR and the manager doing the hiring, Hsieh personally interviews the candidate and makes the final call.  His strategy is to get the applicant into a social situation to see if they can connect emotionally.  Alcohol often figures in the hiring process.  “I had three vodka shots with Tony during my interview,” says Rebecca Ratner, Zappos’s head of human resources.  “And I’m not atypical.”  I asked Hsieh if this wasn’t exposing the company to unnecessary risks.  “It’s a risk,” he says.  “But if we’re building a culture where everyone is friends with everyone else, it’s worth the risk.”

For my college project we never had a chance to conduct an interview.  Could we have figured out Rick would be a problem with a bottle of Jack and a couple of shot glasses?  Should a social situation with a few drinks and attempting to identify an ‘emotional connection’ be the tie breaker in an interview?  Can you scale this process as your company grows?  Could this be implemented at Apple or IBM?  How different would corporate America be if most job interviews started and ended in a pub?

For now I’m going to sit back and watch the Zappos story unfold.  We already know for most of the working world the non-alcoholic approach to hiring works pretty darn good.  We’ll see how Zappos fares in the long run, and what side effects hiring for culture will have as the company ages and their core culture changes.

I’m hoping for the best, I wouldn’t mind sitting down and relaxing with a nice tasty beverage the next time I conduct job interviews…a taste beverage and maybe a plate full of nachos.

Understanding the Wheel

Jun 17th, 2009
by Benjamin Hysell.
Comments are off for this post

I hate reinventing the wheel.

The phrase ‘reinventing the wheel’ is tossed around in software development, as it likely is in other professions, to signify you are probably doing something someone else has already done.  Moreover, others who have solved your problem have hopefully had a chance to iterate on the solution several times to find an optimal answer.

With all this time and effort invested by others why bother trying to duplicate all that effort?  After all, others have already solved your issue, no sense trying to out do them, is there?

Like all issues, reinventing the wheel in software development is not so black and white.

Jeff Atwood wrote about not reinventing the wheel unless you intend to learn more about it: http://www.codinghorror.com/blog/archives/001145.html

Joel Spolsky wrote a few years back that reinventing the wheel is a very good thing if that wheel happens to run your business: http://www.joelonsoftware.com/articles/fog0000000007.html

It is these two key points that will hopefully dictate when you as a software developer decide to break out the case of Mountain Dew and start coding your problem from scratch or to pull a code snippet off of http://stackoverflow.com/ and plug it into your production code.

I am a huge proponent of not reinventing the wheel.  I used to expound to my developers constantly that I am a very lazy programmer.  Why should I spend the time and effort to code something up from scratch if someone has already done all of the legwork?

What isn’t normally fully communicated to someone when I say, “be lazy and don’t reinvent the wheel,” is you have to understand the wheel to know that you are reinventing it.  This is the point Jeff makes at the very bottom of his article, http://www.codinghorror.com/blog/archives/001145.html:

If anything, “Don’t Reinvent The Wheel” should be used as a call to arms for deeply educating yourself about all the existing solutions — not as a bludgeoning tool to undermine those who legitimately want to build something better or improve on what’s already out there.  In my experience, sadly, it’s much more the latter than the former.

I get to be lazy, reuse my old code, and not reinvent the wheel because I understand the wheel I am about to not reinvent.

I have done a bit of legwork myself to understand the piece of code I am about to plug into my system before choosing to plug it in.  I have done some research on the forms to see how others are tackling the same problems I have, and I have done some testing to ensure what I am about to use is going to work.  With all of this legwork under my belt hopefully the next time I encounter a similar problem I won’t have to work so hard for a solution, in effect be a little lazy and modify or tweak an already existing solution to use in a new problem.

It is with this experience that one can become truly effective at producing robust software, learn from the past, and not treat every problem by starting with a blank sheet of paper.

However, one also needs to be smart enough to know when to break out a blank project in your IDE and start from scratch.  As Joel points out in his article, if the piece of code you are about to borrow is a key piece of your product, and this code is going to differentiate your product from your competition you might want to get to know the ins and outs of that code yourself.

What do you do in your software or business that sets you apart from everyone else?  Whatever that is, don’t outsource it or borrow it from others!  If you do you are at the mercy of others for what you are claiming is your advantage.

Joel gives several examples in his article of items not to outsource those items are the cornerstone of your business.  One more recent example Joel did not reference was Zappos.

Zappos sells shoes online.  That is their whole business, online shoes.  Not special fancy shoes you couldn’t buy a hundred different places, just normal run of the mill shoes.

Yet, they are one of the more successful companies operating today on the Internet.

http://www.inc.com/magazine/20090501/the-zappos-way-of-managing_Printer_Friendly.html

Zappos prides themselves on their customer service and quick and speedy order fulfillment.  Guess what are the two things they don’t outsource?  The one part they can’t outsource, the actual delivery of the shoes to your door, they compensate by paying out of their pocket for overnight delivery on most orders to give the end user the allusion of faster than normal service and fulfillment.  Zappos has taken to heart the idea of what sets them apart from everyone else is customer service, and they do everything in their power to ‘reinvent the wheel’ when it comes to that.  They are reinventing the wheel to make a better wheel, a wheel more and more people are starting to use.

I leave you with these thoughts:

  • Don’t reinvent the wheel.
  • Understand the wheel well enough before making a judgment call to reinvent it or not.
  • If the wheel is the corner stone of your software/application/business, you had better be reinventing the heck out of that wheel.

Your Baby is Ugly

May 13th, 2009
by Benjamin Hysell.
Comments are off for this post

I’m not kidding, you have one ugly baby.

Its not your fault…well probably not your fault.

Did you drop him a lot in the first few weeks you brought him home?

No?

Hmm….

I’ve never personally had this conversation with anyone,

::Two points

  1. Yes, I’ve seen this done on Seinfeld…if you haven’t watched Seinfeld go grab a copy of the complete series.  It still holds up.
  2. I actually did see someone tell somebody their puppy wasn’t cute…so sort of in the same vein as telling someone their child is ugly.  Needless to say, “awkward” doesn’t being to describe the mood the conversation took on.

I digress…::

I’ve never seen anyone tell a parent their child is ugly, however, when it comes to creating software, I advocate telling people who write ugly code that yes, indeed, your code child is ugly.

First, for those of you who don’t design software and write code for a living a little background on the parent/child relationship people have with their software.

Software, like children, requires massive amounts of time and energy.  You, as a designer/architect/coder, conceive the code, often times starting with little more than a blank page.  From there, you outline the basic functions of your code, you test your code to make sure it meets specifications, and you clean up your code to ensure it follows all of the best practices dictated by your company.  Hopefully, in time, when your code is completed you can send it off to play with all of the other code in the system.  With any luck, you’ve written a good piece of software that is well behaved, has good manners, and is robust enough to function for many years to come with very little maintenance.

However, with all of the work that goes into the code sometimes it just turns out ugly.

What is ugly code?  Ugly can be described in so many ways…it could be:

  • Inefficient, taking way too long to perform simple tasks
  • Overly complex, possibly a piece of code performs a task in 50 lines where if someone took some time with the code and refactored it the same task could be performed in 10.
  • Incorrect, not producing the correct results.

This is by no means a complete list, but a small sample of items I have run into in my career.

Like anything anyone spends any amount of time with people often grow attached to their output.  With such an attachment people do not take kindly to having that output being called ugly, be it real life children or code ‘children’.

However, as I have said, it must be done…

To their code children, not their real life children…. geez you are a monster.  I’m not sure you should continue reading this blog…

If you can control yourself and your urges for calling kids ugly please continue, we have much to discuss.  Otherwise, I bid you good day.

How you tell someone they write ugly code is up to you.  I don’t advocate sending a company wide email letting everyone know that Johnson can’t write a for loop to save his life, and he would serve the betterment of mankind if he never touched another keyboard.  No, that’s just mean.

Nor would I post their code on the refrigerator and write a large ‘F’ on top of it with a red sharpie…although humorous, after sending that first company wide email Johnson may get the impression of not only do you think he is a horrible coder, but you might not like him either.

No, I’ll leave the delivery of the bad news to the parent of the ugly code up to your discretion, but something must be said, because lets face it, that ugly code child is going to grow up and become your whole team’s responsibility.

Failing to correct ugly code when it is first generated leads to all sorts of problems and heartache.  Firstly, for you, you will likely be the one on call when the code begins to fail in your company’s application, and it will be up to you to fix it at 3am on Christmas Eve.  You will be up all night attempting to track down the module that is failing, and once you find it you will attempt to get something working as quickly as possible, because every second the system is failing your company is losing money.

This is no way to conduct a career…working under the gun to fix a problem, hopefully you didn’t cause.  Especially if it could be avoided by telling the original designer they created one ugly child, and you, for one, do not want to support it when it starts misbehaving and throwing a temper-tantrum.

I recommend several steps in approaching and telling someone they have just written some ugly code:

  • Come out and say, ‘I’m not calling your code ugly, but we need to talk about how you implemented requirements x, y, and z.‘
  • Lay it on the table that there are concerns about the code, not the person who wrote the code.  Attempt to separate the parent from the child.
  • I suggest approaching this situation as a learning exercise.  Point out why you believe the code, although possibly technically correct, has room for improvement.
  • Make sure people know during this exercise this isn’t an indictment on their ability to program or create working algorithms, it just so happens this one isn’t up to snuff and needs some work.  The important point is to stress this isn’t personal and you hope to fix the code to avoid problems in the future.
  • Be able to back up your suggestions on how to fix the code with industry standards.  Share with the individual why you believe their approach isn’t quite correct and show how it is done everywhere else in the industry.  Even if you don’t have Johnson’s full respect it is very difficult to argue with how the rest of the world performs a task.

Lastly, put others at ease around you by inviting them to call your code ugly.  Separate yourself from what you have created and attempt to learn from their years of experience.  It’s the ability to take criticism and to learn from it that will help you grow in your career.

Management Books are Bunk

May 9th, 2009
by Benjamin Hysell.
Comments are off for this post

This article was kicked up last week on Hacker News, http://news.ycombinator.com, and I thought I would share it here with the group.

The Management Myth by Matthew Stewart:

http://www.theatlantic.com/doc/print/200606/stewart-business

This is a long article…long even by my standards.  Set aside some time and curl up with your laptop and a frosty mug of your favorite beverage.

For those of you who find you can’t spare half a day’s time reading about management theory, and who can blame you, allow me to sum up a few of Stewart’s key points regarding modern business management:

  • Management books are bunk, don’t waste your time
  • Frederick Winslow Taylor, author of the Principles of Scientific Management, is regarded as the father of scientific management.  Steward describes how Taylor formed his management theories with a short story about a bunch of workers moving pig iron.
  • The story goes…ask a bunch of workers to perform a task as quickly as they can for a short period of time.  Take that data and extrapolate out what a worker could do in an entire day.  Lastly account for lunch, breaks, and rest periods
  • In this instance Taylor took precise measurements of how much work was being done over a short period of time, but when he accounted for breaks Taylor just picked a number out of thin air.
  • The question arises, why perform such detailed analysis of the work and then just throw a giant fudge factor into the equations when accounting for everything else?
  • Although most modern management books treat Taylor as a footnote in the history of management, at the core of all of these books are the same principals…appear to have a scientific measurement of how to manage people and then throw in a giant fudge factor to account for the ‘human’ aspect of management.
  • The article goes on to describe the work of Professor Elton Mayo in the 1920s, describing that if people care about what they do they will work harder for the greater good of the company.  This is the ‘humanist’ theory of management.

Stewart sums up these two viewpoints:

Between them, Taylor and Mayo carved up the world of management theory.  According to my scientific sampling, you can save yourself from reading about 99 percent of all the management literature once you master this dialectic between rationalists and humanists.  The Taylorite rationalist says: Be efficient!  The Mayo-ist humanist replies: Hey, these are people we’re talking about!  And the debate goes on.  Ultimately, it’s just another installment in the ongoing saga of reason and passion, of the individual and the group.

I’ve read this article a couple of times now, and have spent a considerable amount of time reflecting back on how I manage the people under me.  As I look back on my career I can recall instances where I have managed using both methodologies, I’ve been Tayloritte and a Mayo-ist, and I don’t believe I’ve settled on either side…I’m not sure I am supposed to pick a side.

I have to ask myself, what is the point of all of these management theories?  What are we actually trying to accomplish when it is all said and done?

From my vantage point it appears as if we are attempting to predict the future.  We are hopeful that if a person is given a task to perform, moving pig iron or writing code, that person can perform that task in a certain period of time.  Based on those estimates we can hopefully derive when the assigned task will be completed and when we can ship product.

I believe I’ve been reading the wrong books in a vain hope to predict the future…Stewart goes on to conclude:

The tragedy, for those who value their reading time, is that Rousseau and Shakespeare said it all much, much better.  In the 5,200 years since the Sumerians first etched their pictograms on clay tablets, come to think of it, human beings have produced an astonishing wealth of creative expression on the topics of reason, passion, and living with other people.  In books, poems, plays, music, works of art, and plain old graffiti, they have explored what it means to struggle against adversity, to apply their extraordinary faculty of reason to the world, and to confront the naked truth about what motivates their fellow human animals.  These works are every bit as relevant to the dilemmas faced by managers in their quest to make the world a more productive place as any of the management literature.

I think I’m going to take Stewart’s advice, I’m dumping my management books and I’m cleaning out my Amazon wish list this afternoon.  I am going to replace those books with books written by the greats.

Define greats however you like, and yes, Douglas Adams does count.

← Earlier Posts Newer Posts →