Whisky Web Day One Recap

Today myself and one of my coworkers attended the WhiskyWeb conference here in Edinburgh, Scotland.  This conference is in its first year, organised by a very small team, and was setup and organised from the ashes of a failed conference in just three months.  Located in the lovely Hub Conference Center (a converted cathedral) on the Royal Mile just steps from the Edinburgh Castle, it’s in a great location for those who have never been to Scotland before.  Most of the hundred or so attendees I met seemed to be from other countries and were really enjoying the city.

The conference technically started last night with a Pub Crawl that started at the bottom of the Royal Mile and worked its way up a series of pubs.  This was pretty well attended and all the speakers were in the crowd so it was a nice way to get introduced prior to the event.

Today the two tracks of talks were help in adjacent halls.  The ending keynote speaker even had a helium remote controlled shark swimming the air above the audience’s heads.  I’ve included some pictures.

Img_0487Img_0484Img_0492

Josh Holmes (@joshholmes) on Failure 

The opening keynote focused on failure, how to learn from it, and why it’s a good thing.  Josh is an American living in Dublin and we got to swap stories about motorcycles and Guiness and life without a car the night before.  I even got drafted to taking pictures of him with his own camera.  A nice short, inspiring, and positive talk to kick things off that was probably pretty foreign for most of the UK attendees.

Some of his main points:

  • You will fail.  It’s unavoidable.
  • A famous quote by former IBM CEO who had an employee make a 600k (in 1950s dollars) mistake.  Instead of firing him, he responded that he “Just spent 600k training him”.
  • Talked about a personal failure on a technical choice: SOAP vs. Remoting
  • “Losers always lose” – don’t give up and become a loser!
  • When times get tough, that’s the time to press on
  • Failure is always an option, so respect that.
  • Fail fast is a good concept, but doesn’t give you leave to be stupid (referencing a recent Michael Church blog post)
  • How to integrate failure into your life in a positive way:
    • TDD – fail before writing your code
    • Business Development – fail before writing your app or starting your company by doing research on your concept or idea.

A good way to start things off.

Rowan Merewood (@rowan_m) –  Estimation: “How to Dig Your Own Grave”

Next up was a talk on estimation and some common pitfalls.

Some Classic Estimation Mistakes

  • Sales creating estimates
  • One guy creating estimates
  • Creating estimates from detailed task lists
    • you know it will change
    • gives misplaced confidence
    • encourages micro management
  • Estimating a day as 8 hours

Moving on he talked about some strategies to get around some of these areas.  First he talked about how hours are too granular and suggested using half days as an example – “from the start of the day could you finish by lunchtime?” which can bring more clarity.

As a project’s length scales out, scale up the increments to 1, 3, 5, 7 days.  Anything over this and you’re not estimating anymore.  In response to the tendency of Agile folks not wanting to estimate or developers thinking estimates are useles: fine, stop calling yourself an engineer!

The last bit of the talk was spent talking about some conceptual models used to communicate estimation processes and risks to clients which were pretty interesting:

  • Good, Cheap, Fast – choose two
  • Triangle with points of Scope, Cost, Time – as you vary them, you vary the area which is the quality of the project
  • the MoSCoW model
  • the Kano model
    • Basic features don’t deliver high customer satisfaction
    • As performance improves, customer satisfaction goes up in a linear scale
    • “Exciter Features” generate a bigger satisfaction the more of them are added

Sebastian Marek (@proofek) – Ten Commandments for a Software Engineer

It took something like 15 minutes to get the powerpoint working on this talk, so I was annoyed before the talk even started, but Sebastian pulled it out and gave a great talk on software engineering principles important to him.

  1. Don’t disrupt legacy systems – extract, blackbox, hide behind an interface.
  2. Don’t reinvent the wheel.
  3. Commit often and make sure your messages are informative.
  4. Document early when the problem and your mind is still fresh.
  5. Don’t fear Q/A – use automated, unit, and functional tests along with a CI server
  6. Design for simplicitly.
  7. Don’t kill maintainability.
  8. Don’t repeat yourself – use copy/paste detection and other tools.
  9. Speak up early and often.
  10. Recognise and retain your top talent.

Brian Suda (@briansuda) on Data Visualisation

This was a very interesting (although I’m not sure how practical) talk that was a bit out of the norm for a technical conference.  Brian lived in the UK for awhile and is currently living in Iceland, authored a book on data visualisation, and spends his time seeing how we can help visualise various data sources.  His very graphically intense presentation was a very refreshing look at some unusual or creative ways to get data in front of users in more practical and memorable ways.

A few points:

  • 3D Charts are not advisable (proportion, view obscure)
  • Pay attention to your “data to ink ratio” (tufte, 1983)
  • reduce visualisation as much as possible e.g. simpler is better, remove unnecessary clutter
  • 2 schools of thought (simple, tufte and nigel holms more complex)
  • He showed several examples of PHP generated SVG visualisations which were really interesting, these are located here: github.com/briansuda

John Mertic (@mertic) – Lessons Learned from Testing Legacy Code

John is a member of the SugarCRM project, and described coming on board a few years ago when Sugar had zero unit tests and zero functional tests.  They’ve spent quite a bit of time changing this, and he discussed some tools to assist on finding bad code.

  • phpcpd – copy/paste detection
  • phpmd  – code quality report
  • phpdcd – dead code detection

He also made great points on the following items:

  • Don’t be surprised when you see crap
  • Better to focus on functional tests first
  • Build a culture of testing
  • Use CI or else tests are useless

Whisky Web Day Two

Tomorrow is a Hackathon located on the exact opposite end of the Royal Mile.  I probably won’t attend but all in all for £50, this conference was a bargain.

Random Point of Ignorance: Keyboards

I keep finding these little areas of ignorance that surprise me.  Today’s episode: British (UK) Keyboards are different from American (US) keyboards.  I never in my wildest dreams thought this would be so, but it’s true.  Instead of the @ sign being above the 2 key, it’s above the Right Shift and shares a key with the single quote.  The Enter key is smaller too, and the double quotes is above the 2 key.

I just thought they’d replace the $ sign with the £ and call it a day.  Oh well, the more you know!

I’ll Probably Never Hire Another Pure SysAdmin

NOTE: Updated Oct 17, See Below

This is a thought that’s been percolating around in my head for the last year or so, but has recently become even more crystalized: I’ll probably never hire another Systems Administrator.  A corollary to this thought would be: if you are currently a Systems Administrator or want to be one, you need to seriously begin planning on how to manage a career that will be mostly deprecated within the next 10 years.

Take a look at the current state of the art in cloud computing:

  • Spin up a server at your favor cloud provider (AWS, Rackspace, etc.), then use Puppet or Chef to deploy your software stack.  Now you’re done.
  • OR, Spin up an App at your favorite cloud platform provider, then push your code out using Git.  Now you’re done.
  • For both solutions, plug in some off-the-shelf monitoring, and you’re operating.

What’s missing here is the configuration, setup, provisioning, doc writing, black magic and/or prayer of setting up the software, hardware, and getting the code running that used to be the domain of the Systems Administrator.  In just a couple of years, deploying a web application has now become almost identical to deploying a desktop application – instead of an installer we’re using Git or Puppet/Chef. Instead of a customer’s computer we’re using a cloud platform or cloud server.

There’s plenty still to do on the networking side, but that’s headed in the same exact direction due to the same exact reasons: we want to be able to clearly define and programmatically execute the deployment of complex networks, just like we can with complex server offerings.

All of this falls under yet another buzzword: Dev/Ops.  Just like the cloud, we’re seeing this being adopted by smaller, nimbler organizations that are focused on web products, but the trend is clear, and there’s really no benefit in doing things the Old Way.  Even if you’re still running your own physical metal servers, you’re going to want to make sure that your own datacenter can leverage this type of workflow.  Now, the watchword to the development team is: it’s not done until I can one-click deploy it.

The laggards on this will be those industries that have regulatory or legal hurdles to overcome with using cloud services (read: healthcare) or the very large companies with services and technology that’s dozens of years old with no migration plan.

SysAdmins and future SysAdmins, you need to figure out where you’ll live in this new workflow.  Probably in the margins around monitoring or desktop support.  Possibly serving as the gatekeeper in a sort of “operations Q/A” role.  Expect small companies to have SysAdmin openings dry up over the next 5-10 years and get prepared.

Updated October 17: Hello Reddit/r/programming and Hacker News!  I wanted to take a few minutes and respond to a few themes that seemed to pop up in comments on HN and Reddit.

  1. I’m not saying Sysadminning is dead – just that the role is quickly changing.  Seems like a lot of people (anecdotally, many Sysadmins) thought I was saying the entire profession is dead.  Yes of course we’ll still need Sysadmins on some level, but the crucial difference is that for many areas of a business these needs will be less and much much different.
  2. Software development is changing too.  On complex deployments, developers can’t absolve themselves of the responsibility to design infrastructure considerations into the solution they’re building on the front end.  It’s a scary thought to think that organizations are out there that don’t have this level of partnership between ops and the devs.  This is why the puppet scripts should be written first and deployed on a test environment that’s identical in as many ways as possible to the ultimate operating environment (another benefit of using the cloud).
  3. Of course, any more complex deployment will need devoted SysAdmins, but like I said above, the skillset and day-to-day job will be dramatically different when wrestling with hundreds of servers instead of dozens.  More and more programming will become the norm and more and more upfront input into the solution will be an absolute requirement.
  4. I received a very thoughtful email from a former SysAdmin of mine (previous company) who pointed out that the job is much more along “system integrator” lines now, and that the internal vs. external network distinction is essentially going away.  I agree.
  5. Whenever your’e generalizing, counter examples abound.  Sure big companies and certain computing environments will still do things the Old Way but I’d challenge readers to objectively think if most business decision makers really want to hire someone and run their email server internally or just pay Rackspace/Google/Whomever to do it and worry instead about their money-making applications.  Even those organizations that need their clusters in house will invest in tech that allows them to mimic cloud operations on their own bare metal infrastructure.
  6. A couple of amusing anecdotes – the comments on HN immediately became more positive after a well known commenter defended the post, and a Googler chimed in as well.  That’s when the upvotes really started coming it seems.  On Reddit, the story was quickly downvoted!  Most users chose either a “genius” or “idiot” assessment of the post.  No real middle ground.