February 21, 2011

WD Billing Strategies: Or why start date and end dates are SO critical

Filed under: General Information,Meta-Company — Ryan Wilcox @ 10:02 pm

Since starting Wilcox Development Solutions I’ve understood two things:

  1. Programmer time is expensive – indeed, prohibitive – to most people or companies.
  2. When people buy expensive things they want to know where their money went. Even at the grocery store you get a big long receipt with your purchase, and programmer time will set you back many grocery trips.
  3. People want accountability – people want to know what I’m working on so they know I’m not just billing them for watching Battlestar Galactica.
  4. Stop times and end times are important, not just durations. Transparency is a big thing for me, so if a client (say) doesn’t want to pay for any hours I work after midnight I can take those hours off their bill and stop working late nights for them. Turns out there’s an Even Better Reason for this too, but I’ll get to that

Once, on a project one of my coworkers was accused of punching in for 8 hours but only working six. (The rational: “Because you always punch in 8 hours, and nobody is that consistent on this project – there’s always other stuff, or lunch breaks or whatever!”).

This guy seems like one of the most honest guys around. Additionally, he seems to me to be machine-like with his consistency and thoroughness, like for example always preferring purity over practicality,. If the guy says he worked 8 hours, he probably did.

Anyway, talking to another coworker, and based on some observations of my own, the “accused”‘s standard MO is to put in 6 hours during the day, but then go home and work 10PM to 12:00 PM. I can confirm this too (kind of) because two or three out of five days during the week I see him on Skype chat, and I’ve chatted (occasionally) about project stuff at those late hours.

So this guy gets accused of timesheet games. He has records that prove his innocence, and some statistics to back up his claims of 95%+ 8 hour days. Luckily.

The client’s time keeping system for this project simply has duration. Yes, I’ve been complaining about this for an entire two years, every chance I get. Luckily whatever system my coworker’s company uses internally must track more information that just duration.

If I had been accused of such a thing I would have literally laughed in the client’s face and thrown 8 pages (times 12 months) worth of invoices at them and let them drown in it.

Yes, Virginia, I bill by the month, and me working full time on a project for one month for you will land you a 7-10 page invoice at the end of that month. No, I don’t think this is excessive, and I will figuratively tear your invoices to shreds, via user stories that your invoice is failing. (To those curious out there: Yes, I am available for hire in this area of meta-consulting.)

The moral of the story: always record start date, end date and duration on your invoices. If you don’t record this you will get burnt. If you have to use another time system to keep track of client hours do not do it unless the system has start and end date, and multiple session support (As a user story now: “As a user I should be able to enter my morning work, then take a non-billable break of arbitrary duration for lunch, then enter my afternoon then take a break of arbitrary duration and possibly enter hours for the evening).

For a while there I was also running SLife, on the paranoid assumption that the start, end and duration dates on the invoice might not be enough, and that the client would want to see proof. (There’s also TrackTime, which does a similar thing). I’d be able to answer the question: “Yes, I was using my computer during those times, and here are the applications and windows I accessed – happy now?”

I don’t run SLife any more ($10/month wasn’t exactly worth it just to keep the paranoid person in me quiet). But for some people, in some situations, this is a life-saver, I’m sure.

Anyway, I even wrote my own time tracking system (sessionnotes.appspot.com) because time tracking systems at the time (2008) didn’t have everything I needed. Now I use sessionnotes and Harvest (Starting early 2010, Harvest now does start/end dates and Very Long Descriptions: two things that are critical for me).

I also assume that either the computer will crash when I’m taking notes, or I’ll want a paper back up copy somewhere also, so I keep handwritten notes of everything I do during the day. These approximately mirror what goes into sessionnotes (sessionnotes has better spelling and less drawings of stick men in hats in it, but it’s the same thing.)

Yes, this is petty crap. But transparency shouldn’t be hard at all, and this is one of the ways you can get easy wins without doing much at all.

February 20, 2011

Introducing Scrum Status

Filed under: General Information,ResearchAndDevelopment — Ryan Wilcox @ 3:07 pm

One of my projects has a problem: while we all try to be in the office for scrum, sometimes we can’t all be. Maybe one person is in the car and can’t talk, maybe another person is on the subway… maybe another person has the day off (but the team needs to know their status).

So I started working on a website to take care of these things, and used this team as guinea pigs. Today I announced this site to the world: Scrum Status

Now we have a centralized place to see the entire team’s statuses, easily. Likewise, it’s easy to make an entry for the day while on the go – scrum status works pretty well on iPhone (even though it hasn’t been specifically tweaked for it).

In the spirit of startup launches I’m launching early, to get feedback. Early testing with my team has ironed out the critical bugs, but now I’m announcing this to the world.

Scrum Status runs on Google App Engine, so I don’t have to worry about scaling issues: 1 person could hit the site, or 5,000 – Google App Engine should be able to handle it.

Interested in technical details? The entire project is open source, and the README has a lot of information about the tech involved: Scrum Status on Bitbucket.

February 11, 2011

The Workflow Git Flow enables

Filed under: Uncategorized — Ryan Wilcox @ 10:31 am

Git flow is awesome, and accomplishes everything you might want easily.

This is (part) of an email I sent out today about the patterns git flow sets you up for, and what that means.

The Broken Build

> Hi guys,
> Can you guys huddle and see about getting the build working again?
> Thanks!
> – Ed The Manager

My Response

I think it’s important to use this time to highlight that most of the
work happens in the “develop” branch in Github. There’s another
branch, “master” that is synced up with the latest when [redacted] does a

Master is what (everything sometimes integration) gets their code from

Take Home Point

Even if the build is broken on the develop branch [ed: which is what the original email was referring to], we’ll always have a
production ready build (on master).

Changes when the build is broken (for production)

If we absolutely must make a production change while the develop build
is broken, that’s also possible with our process and this “git flow”
tool we use. (we do our work and put it on master, not on develop).

BUT if we release when we have a broken build, we:
(a) We lose that “know good” state we can make critical fixes.

(b) possibly introduce bugs (that the tests are trying to point out to us)

In Production

The coming pressure of “a bug in production” will also try to force
the “release this branch now, broken build or not!” Again: we have
process for that (production critical bugs should happen as what git
flow calls “hotfixes”

The point: if we as a whole Agile team, don’t release
(putting the develop branch into the master branch) when the build is
broken, we’ll always have a “known good” point we can issue emergency
hotfixes for production issues.

And we can deploy this “master with this new hotfix” and start the deployment
process with them.

Too Long; Didn’t Read

The develop build could stay broken for days, and it doesn’t matter,
with the pattern we are using. Production fixes can go in and the
client will see responsiveness.

The master build, yes, the concerned stakeholders should/could watch to remain informed of the state of the production-ready code. Broken builds here are “drop everything” critical issues.

Hope this explains our process, and how we can accomplish change even
if we’re waiting on the build to be fixed elsewhere.


Git flow is a standard tool at Wilcox Development Solutions. We love that it enables developer productivity and forward motion, while enabling being responsive to the customer on critical issues.

While having a broken develop build is bad, and should be fixed, ideally the team itself should manage itself in this way (via peer pressure and professionalism), instead of this being a critical management issue. Because management has other things to worry about.

February 1, 2011

Lesson from W. Edward Deming on software

Filed under: General Information — Ryan Wilcox @ 10:45 pm

Over this weekend I read some of W. Edward Deming’s Out Of Crisis. Deming was a man credited with the success Japanese industry had after World War II. I’m 100 pages into the book and have already pulled out much information

Saturday I read:

… Next day, in one of his plants, a superintentant showed me two pieces of a certain item from two different suppliers, same item number and both beautifully made; both met specifications, yet they were sufficiently different for one to be useable, the other one usable only with costly rework, a heavy loss to the plant

In short: context is important, and understanding context more so.

A similar thing just happened to me.

A few months ago I created some import functionality for a client – import a file and add it to some table in the database. So we followed the spec exactly: wrote that file to a table. Writing to that table in isolation, because the specs (even through digging and talking with the customer) specified only that.

Today I find out that this table actually is a major reference table that needs to tie into the app in two different places. This discovery means we have to revisit that import even though we implemented it exactly per specification the first time.

Not knowing the context caused extra work and added delay to a software project that was already under schedule risk

Lesson here: Your consultant wants both of you to succeed. As much as you can, provide context for where this functionality will fit in the bigger picture. In exchange for that you’ll get better more quality product in the end, and probably your product will ship faster, and have fewer bugs, than without that context.