Skip to content

Run through the finish

Make that last code change.

Write that last test.

Look in that document, rather than trying to remember what color the icon is supposed to be.

Write that documentation.

Look at your work with the eyes of a user.

I work in a small development department (2 developers plus a number of contractors) and I need to constantly remind myself to run through the finish.

I ran in high school and college (cross country and track) and at the very end, it is easy to let your guard down and coast.  After all, you’ve done almost all of the hard work.  And no one is really behind you.  And it hurts (oh yes, it hurts).  So, why not ease off a bit?

The problem is, there is someone behind you, and they have you in their cross hairs.  They have the incentive and the vision of their competition, but you have the lead.  Why give up any advantage?

Development isn’t painful, but it can be a slog.  Yes, yes, I’m sure there are shops that never have a slog.  But, for most mortals, there are requirements that are changed or were forgotten, tasks that are less fun than others, tweaks to the UI for the Nth time, vendor rigidity that never surfaced during the sales process, and other sundry annoyances.  But you as the developer own the final product.  You can choose to coast, since you did 99% of the work (and did it well), or you can choose to run through the finish.

Run through the finish.

How do you decide to pull the plug on a project?

Over the past six months, I’ve been involved with two projects that, to put it politely, didn’t go exactly as planned.

Project A was cancelled, after a significant amount of preparatory work had been done, and project B was just released, after a much more significant amount of effort was expended.

What caused one to be cancelled and the other to be continued?

  • Timing: A had a tight schedule, with a deadline that made sense from the business’ perspective.  When it became clear that the deadline would be missed, cancellation was a logical option.  B had goals but no deadline, which made it harder to make a go/no go decision
  • Risk: A required some server rejiggering that would have made it extremely difficult to roll back.  B, on the other hand, would have been a simple software re-release to roll back to previous, somewhat working, software.
  • Business impact: A was a ‘nice to have’ project, whereas B was addressing something that had caused employees and users pain for years.
  • Sunk costs: A had fewer sunk costs than B, which paradoxically made it easier to cancel (paradoxically, because you should not consider sunk costs when looking at an investment).

What is the difference between pushing through to finish a difficult project and polishing a turd that you really should abandon?  It’s a fine balance, and as project B dragged on, I wasn’t sure at times which path we were headed down.  As someone who loves to ship, it’s hard for me to give up on a project that I had a hand in building, but no business writes software in a vacuum, and those business needs can and do serve as valuable checkpoints on the software process.  Because of the huge business value, it made sense to push through on project B.

Sometimes business priorities change, or, as in the case of project A, deadlines impose a different set of priorities (beyond the purely technical).

Regardless, I think that the more I consider any projects I have dragging on through the lenses of timing, risk, return and sunk costs, the easier it will be to make a go/no go decision.

Using Munin To Track Business Values

Munin is a great piece of software that we use at my company to track overall trends in disk usage, CPU and other system purposes.  Now, we don’t have a ton of servers, so I’m not sure how munin scales for many machines, but it has been invaluable in troubleshooting problems and giving us historic context.

One thing we’ve started to do is to incorporate business specific metrics into munin.  This is good because it ties the technical operations more tightly to the business, making us aware when there are issues.

Anything you can run a sql query or do a wget for, you can graph in munin.  (Here’s something I wrote about writing munin plugins a year ago.)

I don’t think that munin is acceptable as a general purpose dashboard.  I’d probably look at Google Analytics if I was web drivingdriven (updated Feb 25 2012), and at statsmix if I needed to integrate a bunch of disparate services.  But for bringing additional business awareness to a technical team, writing a few custom munin plugins that will graph key business metrics can be very useful.

Hiring Tips

I’ve only hired a few times, but I just wanted to jot some notes about what worked for me in this process.

  • Use a bug tracker or issue tracker to keep track of resumes, emails and interactions
  • Respond to every person – there were some outsourcing firms that I didn’t respond to, but every other person got a response from me
  • Use Craigslist.
  • Use an email alias on your Craigslist post
  • Use other mailing lists (rmiug-jobs, cu cs jobs, even local neighborhood lists)
  • Ask your networks for candidates, but don’t expect too much of them
  • Pre-screen with a set of email questions if possible.  Don’t ask candidates to do too much, but asking them to do some work will allow some to self select out
  • When doing an interview, set the candidate up to succeed, by telling them what you are planning to ask them to do
  • Set deadlines for yourself, and share them with the candidates
  • Follow up with every candidate when you make a decision – I don’t think that it is fair to do otherwise
  • If you can point job seekers at another position, do so.  I recently did this with a QA position – in my search, I discovered another firm that was looking to hire, so I pointed all the candidates that didn’t work for us to that firms job posting
  • The web is full of sample job interview questions – use them!

 

On Being Disrupted

This is a tough post to write.  I’m at the tail end of an evaluation process for my company that ended up with us deciding to go with a third party vendor for software which powers key area of our business.  It is augmentation rather than replacement, but still.

It was hard for me, because this particular key functionality was previously provided by custom software that I helped build over years.

I like to build things!  Like most other software developers, I get excited about building stuff.  One of the unmentioned frustrations of many software developers is building something and then seeing it shelved.

However, it was clear from the survey of solutions that there were three choices:

  1. buy something off the shelf
  2. get better as software developers and really, really accelerate our development
  3. have the business be negatively affected by this piece of software

Now, #3 is obviously not a good solution.  #2 is a great solution, but is hard to put into practice, especially in a short time frame with a large code base (though we are trying to use some of the agile methodologies to make our software development more productive).

#1 it is.

Was this a wise choice?  Talk to me at the end of the implementation, but I am hopeful.  We did take several steps to protect ourself (after all outsourcing core business functionality can be deadly), including:

  • a long, laborious evaluation
  • engagement with multiple vendors, and
  • building a set of criteria to help us determine if this outsourcing is meeting our needs

One thing that helped me take this decision a little less personally is to redefine in my mind the value of software to the company.  It’s not the particular implementation of the software that provides the value.

Unlike a software company, my company doesn’t exist to write software (see Five Worlds for more on different types of sofware development).  Instead, software exists to serve the company.  Having something off the shelf provides the similar functionality for much cheaper.  It also allows me and other members of the software team to write software that is unique.

Having been a contractor and having worked for a startup and consultancy, I’m used to being the disruptor.  In this scenario, I was the disrupted (ht, David Skinner).  It’s a humbling place to be, even if I wasn’t disrupted out of a job.

Word to the Wise

I recently read this post about startup team success from Paul Graham.  Always fun to read Paul–I have a few sites I remember and type in periodically (haven’t used an RSS reader since Bloglines), and paulgraham.com is one of them.

The older I get, the more I see that being resourceful and having follow through are very very valuable traits.  This post just confirmed that.

The corollary to that is, if you don’t think you are going to follow through on a suggestion or a favor someone asks of you, it’s far better to say no up front than to fail to follow through.  That is going to be a tough lesson to integrate into my life, but it’s the flip side of that coin.

8z Real Estate Hackfest

Recently, at the company I work for, 8z Real Estate, we had a hackfest.  A hackfest, for those not in the know, is a chance for employees to spend time working on whatever they want to do but don’t have time to do during the normal business day.  It’s also known as ‘FedEx day’ because you build something to ship in one day.

The idea is to give everyone a chance to do something work related that they want to do, or try, or explore, but don’t have time to because of the hustle and bustle of work life.

From the post at Atlassian (as far as I know, the originators of FedEx day).

[The] task must be something “out of the ordinary”. This is hard to define – but basically the spirit is that you can’t do something you would normally do. It’s a chance to attack all those “I wonder if XYZ would work… “, “It would be nice if we could… ” small … tasks that always get pushed off in the heat of battle.”

We had about 11 employees and contractors gather at the office.  Our schedule:

  • 8:00 Employees arrives, normal work begins
  • 10:00 Employees cease normal work
  • 10:00 – 10:30 brainstorm session
  • 10:30 – 10:45 pick projects
  • 12:00-1:00 eat lunch (Snarfs!)
  • 10:45-4:15 continue work on project
  • 4:30-5:30 present projects (8 min presentation) and drink a beer

We had an 2 hour block of work at the beginning of the day because we needed to, but after that, almost no one did everyday work.  Phones were off, email was closed.

The type of projects selected varied.  Most folks weren’t developers, so we didn’t have a ton of shipped software.  But we had some really interesting ideas, ranging from investigation of interesting technologies (what’s coming down the pike with our e-newsletter sender, infographics) to outlines of business ideas, to refactoring of business processes.

The excitement of all working together, in one room, on different projects, for a fixed amount of time, with no interruptions was one highlight.  I also really enjoyed people’s varied takes on aspects of the business.  It was also impressive to see the skills that I didn’t know some people had (powerpoint, for one).  It was awesome how many good ideas we had, even though some of them would have taken a hackfest week to implement.

All in all, it was a worthy experiment and something every business should consider doing.

Help A Reporter Out

This site, Help A Reporter Out/HARO, is a great resource for anyone with expertise in any field who wants to be better known. (It’s also a resource for journalists, but I don’t have any experience with that side of the site.)

To participate as a source, you sign up and then are sent three emails every work day. Every email consists of 35-50 reporter queries, grouped by area (‘Travel’, ‘Tech’, ‘Education’, etc). Included in each query is the deadline, name of the reporter (if provided), anonymized reporter email address, and media outlet. There’s also some advertising, but I tend to skip past that (although I did click once on an ad that led me to learn about Google Apps Scripting).

Once you get the email, you scan the queries and see if you can and want to respond to any. I recently responded to one, but before that I’d passed off a number of requests for information to other people. Such handoffs are a great way to help other people out, and it’s kinda fun–who doesn’t want to talk to a reporter? (Psst, if you’re looking for a job, sending over a reporter query related to a company’s business is a great way to build rapport with people there.)

As I said above, a few days ago I’d finally found a query I felt I could help with, and responded with an email answering the reporter’s questions. The reporter responded, and I ended up have a 10 minute phone call about the story. So even when you actually participate, it’s pretty low impact.

I will say the hardest part of participating in HARO for me is scanning the emails–scanning 150 queries a day wears me down. I’ve stopped scanning them all, but still check from time to time.

I just think this is the coolest example of something that the internet allows, but couldn’t happen (at scale) any other way. The costs, both in money and time, of sending out and responding to reporter’s queries would be just too high.

Running a Google Apps Script Once a Month

I needed a way to email a Google spreadsheet to my boss once a month, for some reporting purposes.  I could have put an entry in my calendar reminding me to do it, but I thought it would be a great time to try out the Google Docs scripting that I had read about for a year or two, and seen an AppSumo video about.  (I got the AppSumo video for free, from an ad on HARO.)

It was laughably easy to get write the actual script (here’s a great set of tutorials).  The only rub was Google doesn’t allow you to run scripts in month intervals, only hourly, daily or weekly.  A small bit of scripting got around that.

Here’s the final script (edited to remove sensitive data):

function myFunction() {
  var dayOfMonth = Utilities.formatDate(new Date(), "GMT", "dd");
  if (dayOfMonth == 05){
    MailApp.sendEmail("email@example.com", "Spreadsheet Report Subject", 
'https://spreadsheets.google.com/a/mydomain.com/ccc?key='+SpreadsheetApp.getActiveSpreadsheet().getId());
  }
}

I set up a daily trigger for this script and installed it within the spreadsheet I needed to send.

I really really like Google Apps Script.  I think it has the power to be the VB of the web, in the way that VB made it easy to automate MS Office, reduce drudgery, and allow non developers to build business solutions.  It also ties together some really powerful tools–check out all the APIs you can access.

Once you let non developers develop, which is what Google Apps Script does, you do run into some maintenance issues (versioning, sharing the code, testing), but the same is true with Excel Macros, and solving those issues is for greater minds than mine.

Source Code Escrow

Have you ever considered asking a software vendor to put their source code in escrow? I recently broached the topic with a vendor I was evaluating. They didn’t seem too happy about the topic (at first, they were a bit sarcastic [“does Oracle do software escrow?”] and then they deleted tech support forum post). I did a bit of research, and there doesn’t seem to be a clear consensus on software escrow. Here are two interesting articles: Are you just following the herd? and Source Code Escrow.

Just having started thinking about the topic, my thoughts are still up in the air, but here’s my first reaction. Source code escrow makes sense when the following conditions are met:

  • The software is not open source (duh)
  • The software is or will be crucial to your business
  • The company is small or the future of the company is up in the air
  • You (the purchaser) have the technical capabilities to support the software should you receive it, or you’re willing to invest in those who can
  • You are willing to pay more for source that will be escrowed

I think of source code escrow like a warrenty on a car, or a professional license of open source software (like RedHat or Alfresco). It’s not for everyone (a car mechanic isn’t going to buy the warrenty) but it’s a nice option to have. And, to stretch a metaphor, if you’re going to soup up your car and build a livelihood on it, it’s nice to have a warrenty.